I need to know what happens when I do a read of a file on an AppleShare server in a remote location over a slow link. In brief, I have a program in Toronto, London, Madrid, Zurich, Frankfurt, and Paris that reads a file from an AppleShare server in New York.
Sometimes the link (Liaison over an asynchronous line into the Tymnet packet Switched network) "breaks" and other times, we seem to "lose" the server. When we try to reconnect to the server, the branch locations sometimes do not "see" the server in the Chooser window for a long enough period to select the server physically. We cannot, therefore, restart the application. Their observation has been 15 seconds of availability. This does not always happen, but it happens too often to not lodge a complaint.
The application checks on and reports all sorts of errors on a read, and it does know when it cannot open a file, because a server is unavailable. I am doing PBHOpenDeny opens and PBRead calls. We have asked the Tymnetnetwork people to look into this, and they have asked the following questions:
1) When you open the Chooser window and select a zone, how do the lists of servers appear?
- How long does it take to get the list up?
- Why do some servers come into and disappear from the list?
- Why do some servers never appear in the Chooser window? Is this because the servers' response time is very slow, and, therefore, the response is ignored until the next request is broadcast? If so, how long is this window? (What is the maximum round-trip delay from the branch Macintosh to the AppleShare server and back?)
2) On a read, when a read request is sent to the remote AppleShare file server (from branch to New York) what is the timeout period before the packet is determined to be lost, and is thus retransmitted?
3) On a normal AppleShare read, if a data packet times out, how many retries are made before AppleShare decides that the link to the server is dead? Or, how long does AppleShare continue trying before it gives up?
4) If I do a read, should I always get back a response, or is it possible that if the Macintosh has lost the file server, AppleShare will be unable to respond, and that the reading application will appear to hang? This seems to happen sometimes, from what the branch people say. Sometimes, if we lose the link to New York, the whole Macintosh hangs and must be restarted.
One issue in versions before 3.0 was the inability of Liaison to display zone lists when the zone list transverses more than one ZIP packet (around 40 zones depending on the size of the name). You should call Farallon to discuss the current issues the account is experiencing with the product. We cannot control how third-parties choose to implement routers and other such products based around AppleTalk. This can cause issues if the product was implemented in a way that the protocols were never designed to accommodate.
Because the AppleTalk protocols were never designed to work over slow asynchronous links or over wide-area networks, there are several issues that need to be addressed before AppleTalk can become a valid protocol for use in these types of environments.
Here are direct answers to your questions:
1) This is how it really works in a nutshell:
The Chooser sends out a Name Binding Protocol (NBP) packet looking for all devices of type XXXXXX, for example, type LaserWriter. It sets up a buffer of 512 bytes for the responses. The responses look like:
device name length 1 byte
device name variable bytes e.g. MyLaser-Hands off
type name length 1 byte
type name variable bytes e.g. LaserWriter
zone field length 1 byte
zone name field variable bytes probably *
The Chooser gets a packet back for each device, i.e., each LaserWriter. When the 512-byte buffer is full of these packets, it stops looking for device names to display. This means that some LaserWriters might not be displayed immediately. If you leave the Chooser window open, however, the Chooser will continue to send out NBP lookups every 1.47 seconds.
Different LaserWriters could respond more quickly each time. In this case, you may see the Chooser show and hide various devices.
You can see from this that the number of devices Chooser can show depends on how long the type name is (like "LaserWriter") and how long the device names are. The number 18 is an average number, based on the device type being about 13 or 14 characters long and the device name being about 10 or 11 characters long. In System 7.0, the buffer size the Chooser will use will be increased to 1024. This means, on average, the Chooser can display about 36 devices.
2) This depends on the direction of the transfer. Workstation to Server copy takes 6 seconds and server to Workstation copy about 2 seconds.
3) Retries are set to infinite. The session timer for the connection is set to 2 minutes. This is really what dictates how long the reads are attempted before the transaction is aborted. The session timer is restarted each time a tickle packet is received by either the workstation or the server. Tickle packets are sent out every 60 seconds by both the server and the workstation to allow a way of detecting if the other end of the connection has gone down.
4) No, you aren't guaranteed a response, but the session timer should expire after 2 minutes and pop up a dialog telling you that the server has unexpectedly quit.