Q: Inside Macintosh, Volume V, lists ATP limitations for the Macintosh
Plus, RAM-based, Macintosh SE, and Macintosh II AppleTalk implementations.
Where can I find the same information for other recent AppleTalk versions? By
the way, what's the difference between the tooManyReqs and the noDataArea
errors returned by PSendRequest and PNSendRequest?
A: ATP in AppleTalk version 58.x has several hard-coded limitations. They are:
- the maximum number of concurrent
SendRequests is 12
- the maximum number of ATP sockets that can be opened is 126
- the maximum number of concurrent XO
SendResponses is 32
- the number of ATP data areas (parameter blocks for ATP's MPP calls) to
- allocate is 8.
PGetAppleTalkInfo returns some information about MPP's limits, but not those
for ATP.
If you use PNSendRequest instead of PSendRequest, your calls will be faster
(because ATP doesn't have to open a socket each time it sends a request) and
you won't be limited to 12 concurrent SendRequests. The maximum number of
PNSendRequests is currently calculated based on the value of the TimeDBRA low
memory global (a word value). We cannot guarantee this formula will always be
used but this is what's currently used:
max number of PNSendRequests = ((((TimeDBRA / 100) * 120) - 142) / 48)
|
For example, TimeDBRA on the Macintosh II is 2620, so ((((2620 / 100) * 120) -
142) / 48) = 62 (That's the same number in the chart on page V-520 in Inside
Macintosh, Volume V).
You can get a tooManyReqs error from either PSendRequest or PNSendRequest if
you attempt too many concurrent requests; 12 for PSendRequest; the number from
the formula above for PNSendRequest.
A noDataArea error is not the same (although your application may want to treat
it the same). When ATP calls the MPP driver to send out a packet (with
PWriteDDP), it has to use a parameter block. As noted above, the number of
parameter blocks available for this purpose is 8. Since DDP write operations
normally complete rather quickly, the chances of 8 calls backing up should be
rare. However, if the limit is hit, a noDataArea is returned and the packet is
not sent.
In most cases, when you get either the tooManyReqs or the noDataArea error,
retrying the request after a short delay should work.
The reason ATP limits concurrent XO SendResponses is that ATP has to keep the
responses it receives until it receives a release packet, or until the
transaction times out.
Remember, your program shares the ATP driver's limited resources with other
network programs running (for example, mail servers, mail clients, the
AppleShare client, the File Sharing or AppleShare server), so you should only
use a reasonable amount of the shared resource.
|
