ADC Home > Reference Library > Technical Notes > Legacy Documents > Networking >

Legacy Documentclose button

Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.

Current information on this Reference Library topic can be found here:

Data Servers on AppleTalk

CONTENTS

Many applications could benefit from the ability to share common data between several Macintoshes, without requiring a file server. This technical note discusses one technique for managing this AppleTalk communication.

[Nov 01 1990]






Introduction

There are four main classes of network "server" devices:

Device Servers, such as the LaserWriter, allow several users to share a single hardware device; other examples of this (currently under development by third parties) are modem servers and serial servers (to take advantage of non-intelligent printers such as the ImageWriter).

File Servers, such as AppleShare, which support file access operations over the network. A user station sends high-level requests over the network (such as "Open this file," "Read 137 bytes starting at the current file position of this file," "Close this file," etc.).

Block Servers, which answer to block requests over the network. These requests impart no file system knowledge about the blocks being passed, i.e., the server doesn't know which files are open by which users, and therefore cannot protect one user's open file from other users. Examples of this type of server are available from third-party developers.

Data Servers, which answer to requests at a higher level than file servers, such as "Give me the first four records from the database which match the following search specification." This note directs its attention at this type of server.

A data server is like a file server in that it responds to intelligent requests, but the requests that it responds to can be more specialized, because the code in the server was written to handle that specific type of request. This has several added benefits: user station processing can be reduced, if the data server is used for sorting or searching operations; and network traffic is reduced, because of the specificity of the requests passed over the network. The data server can even be designed to do printing (over the network to a LaserWriter, or on a local ImageWriter), given that it has the data and can be directed as to the format in which it should be printed.

Back to top

ATP: The AppleTalk Transaction Protocol

ATP, the assured-delivery AppleTalk Transaction Protocol, can be used to support all types of server communications (the LaserWriter uses ATP for its communications!). Here is a possible scenario between two user stations ("Dave" and "Bill") and a data server station ("OneServer", a server of type "MyServer"). We've found that the "conversational" analogy is helpful when planning AppleTalk communications; this example is therefore presented as a conversation, along with appropriate AppleTalk Manager calls (Note that no error handling is presented, however; your application should contain code for handling errors, specifically the "half-open connection" problem described below).

Back to top

Establishing the Connection

Each station uses ATPLoad to make sure that AppleTalk is loaded. The server station, since it wants to accept requests, opens a socket and registers its name using NBPRegister. The user stations use NBPLookUp to find out the server's network address. This looks like this, conversationally:

Server: "I'm ready to acceptAppleTalk requests!"

ATPLoad Opens

OpenSocket Creates socket

NBPRegister Assigns name to socket

ATPGetRequest queue a few asynchronous

ATPGetRequest calls, to be able to handle several

ATPGetRequest users

Dave: "Any 'MyServers' out there?"

ATPLoad Opens AppleTalk

NBPLookup look for servers, finds One Server

Dave: "Hey, MyServer! What socket should I talk to you on?"

ATPRequest Ask the server which socket to use for further communications

Bill: "Any 'MyServers' out there?"

ATPLoad Opens AppleTalk

NBPLookup look for servers, finds OneServer

Bill: "Hey, MyServer! What socket should I talk to you on?"

ATPRequest Ask the server which socket to use for further communications

Server: "Hi, Dave! Use Socket N."

ATPOpenSkt Get a new socket for talking to Dave

ATPResponse Send Dave the socket number

ATPGetRequest Replace the used GetRequest

Server: "Hi, Bill! Use socket M."

ATPOpenSkt Get a new socket for talking to Bill

ATPGetRequest Replace the used GetRequest

From this point on, the server knows that any requests received on socket N are from Dave, and those received on socket M are from Bill. The conversations continue, after a brief discussion of error handling.

Back to top

Half-Open Connections

There is a possibility that one side of a connection could go down (be powered off, rebooted accidently, or simply crash) before the connection has been officially broken. If a user station goes down, the server must throw away any saved state information and close that user's open socket. This can be done by requiring that the user stations periodically "tickle" the server: every 30 seconds (for example) the user station sends a dummy request to the server, which sends a dummy response. This lets each side of the connection know that the other side is still "alive."

When the server detects that two intervals have gone by without a tickle request, it can assume that the user station has crashed, and close that user's socket and throw away any accumulated state information.

The user station should use a vertical-blanking task to generate these tickle requests asynchronously, rather than generating them within the GetNextEvent loop; this avoids problems with long periods away from GetNextEvent (such as when a modal dialog box is running). This task can look at the time that the last request was made of the server, and if it's approaching the interval time, queue an asynchronous request to tickle the server (it's important that any AppleTalk calls made from interrupt or completion routines be asynchronous).

If a user station's request (including a tickle request) goes unanswered, the user station should recover by looking for the server and reestablishing communications as shown above (beginning with the call to NBPLookUp).

More information about half-open connections can be found in the Printer Access Protocol chapter of Inside LaserWriter, available from APDA.

Back to top

Using the Connection

The user stations Dave and Bill have established communications with the server, each on its own socket (note that the user stations have not had to open their own sockets, or register names of their own, to do this--the names we're using are merely for explanational convenience). They are also automatically tickling the server as necessary.

Now the user stations make requests of the server as needed:

Bill: "I'd like to use the sales figures for this year."

ATPRequest Bill opens a database.

Server: "Ok, Bill."

ATPResponse The server checks to make sure that no one else is using that database.

Dave: "Hey, Server - I'm still here!"

ATPRequest Dave notices that the interval time is approaching, and makes a tickle request.

Server: "OK, Dave."

ATPResponse The server resets its "last time I heard from Dave."

Bill: "Please print the figures

ATPRequest Bill asks for specific data for January thru June."

Server: "OK, Bill."

ATPResponse The server does a database search, sorts the results, and prints them on a local Imagewriter.

Dave: "I'd like to use the sales figures for this year."

ATPRequest Dave opens a database.

Server: "Sorry, Dave, I can't do that. Bill is using that database."

ATPResponse The server finds that Bill is using that data.

Back to top

Closing the Connection

The user stations continue making requests of the server, until each is finished. The type of work being done by the server determines how long the conversation will last: since the number of sockets openable by the server is limited, it may be desirable to structure the requests in such a way that the average conversation is very short. It may also be necessary to have a (NBP named) socket open on the user station, if the server needs to communicate with the user on other than a request-response basis. Here is how our example connections ended:

Dave: "Thank you, server, I'm done

ATPRequest Dave tells the server he's finished now. You've been a big help."

Server: "OK, Dave. Bye now."

ATPResponse The server kisses Dave goodbye.

ATPCloseSkt After the Response operation completes, the server closes the socket Dave was using. It also

ATPCloseSkt notices that Bill hasn't sent a request in more than two intervals, and closes Bill's socket, too.

The user station can forget about the socket it was using on the server; if it needs to talk with the server again, it starts at the NBPLookUp (just in case the server has moved, gone down and come up, etc.).

References

The AppleTalk Manager Inside LaserWriter

Back to top

Downloadables

Acrobat gif

Acrobat version of this Note (56K)

Download


Back to top


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.