Date: Fri, 28 Jul 95 12:25:06 +0100
From: jdavies@csd.co.uk (Jem Davies)
To: (Kevin) kwelton@acorn.co.uk
Subject: Net module and !Gateway problem
Return-Receipt-To: jdavies@csd.co.uk (Jem Davies)
Message-Id: <3018D722@jdavies@csd.co.uk>

Martin

As requested, I have looked into the problem with the Net module and
!Gateway machines.

There is (and always was) a time window between the reception of the first
packet from a !Gateway machine (that essentially tells the station that it
is not 128.<stn> but <net>.<stn>) and the reception of the map information
from that machine. During this time, an attempt to access other stations may
fail due to the absence of the map information.

The difference between the cases of NetFS file servers being configured by
number and name is one of timing. When configured by number, NetFS performs
a machine-type peek to ensure that the file server machine is present before
attempting to talk to it. When configured by name, a broadcast to find the
file server is required first. This delays matters until after the window
described above has been closed.

The window can occur during Net module (re)initialisation, or when a
!Gateway machine is started at a later time. During machine startup, the old
code delays during the initialisation entry of the Net module, calling the
dreaded usermode_donothing() to see if a response from a !Gateway machine
is forthcoming. The new code only does this if all the other modules are
present and happily installed (particularly Internet and a device driver) to
prevent unnecessary delay.

The debug output provided by Kevin that I examined does not have the device
driver present initially (or at least not responding, it may not be fully
initialised), and so does not perform the delay during initialisation. The
device driver announces its presence via a service call, and the Net module
reinitialises itself on a callback, after receiving that service call.
Communication with the !Gateway machine then occurs in the background while
the rest of the machine (in particular, NetFS) is being initialised. This
leaves the window wide open, and we fall into it! This problem would not
have occurred with the old code because the old code would have refused to
initialise if the device driver were not present.

Attempts to fix the problem could be directed at closing the window properly
during all circumstances, which may be difficult, or perhaps looking at
avoiding the problem during machine startup which might be somewhat easier
and might remove most of your problems. It really depends on how much of a
problem you believe that this fault is causing you. What would you like me
to do?

Jem
