brad@gcc-milo.UUCP (Brad Parker) (10/26/86)
Just a note to all you CAP hackers out there (this includes users of
the CAP/EFS code)
It is a known fact (confirmed by Apple) that the ATP protocol has a
"hole" caused by dropped Trel packets. That is, if a Trel (release)
packet gets dropped, the .ATP driver's internal tables will not free
up soon enough to allow for high-volume transaction processing. Apple
recommends canceling responses as soon as you know they have been
received.
So what you ask?
Well, when you start using the CAP/EFS code with interbridges, the
likelyhood of dropping Trel packets goes way up. So, you soon
notice that your efs connection begins to "studder" or slow way down
for short periods of time. This is because a Trel was dropped and
the efs daemon does not put up another getRequest until the last
getRequest completes. The cache timeout is currently 30 seconds
(rather long for my taste) for unreleased responses.
A simple solution is to use two getrequests. Always have one getRequest
pending and always cancel the responce on the previous getrequest when
you get a new request. (this only works if you know your "client"
will only send one request at a time - which works with the EFS code)
Needless to say, a session protcol would take care of all of this.
If you need a more coherent description, don't hesitate to mail.
-Brad Parker
--
J Bradford Parker
General Computer (HyperDrive Beach, 3rd Cabana)
harvard!gcc-milo!brad
Good Sex is easier than a good slow roll. ("Left Stick! Right Rudder!...")