[fa.info-mac] Suggested changes to the DDP interface of MPP

info-mac@uw-beaver.UUCP (07/12/84)

From: Mark.Sherman@CMU-CS-A.ARPA
I would like to exchange some ideas with other people using the MPP,
in particular, those trying to use the DDPCall interface. There are a
couple of things I do not like and have changed. I am wondering what
other people think and have done:

1) One can read only one socket at a time. Although I can understand
Apple's comment that you should use the protocol field to
distinguishing protocols, I may want more than one conversation at a
time, which I distinguish by socket number.

2) One can lose a packet event w/o any way to know or recover.  When a
packet arrives, OURSL will fill in the packet buffer and try to post
the APPL2 event. It then clears out the buffer length (and socket) to
indicate that the read has completed. If the event queue is filled,
then the PostEvent call will fail so the program will never know that
the read was satisfied but lost.  There is no way for the program to
ask the DDP package if this has happened; one can just watch the time,
assume something went wrong and issue another read. This approach is
inappropriate if you do not know how fast (or slowly) packets will be
coming.

For the first problem, I changed OURSL so that the passed destination
socket number (in DDPRead) is not used in deciding whether to reject
or accept a packet, and changed DDPRead and OURSL so that the source
socket parameter is passed by VAR -- the socket on which you received
a message is "passed back".

There are a number of approaches to the second problem. First, one
could just keep calling DDPRead with the same parameters, since the
call would just write the parameters into the same static local
storage for OURSL. Second, one could try to give network events high
priority with the hope that by servicing network events fast enough,
there would be enough room in the event queue for more. Third, one
could try to transfer events of out the event queue into a local queue
which could be larger and be processed at liesure (for example moving
keystrokes out into a separate event queue and then processing them in
batch). I took a fourth approach and changed DDPRead so that once
called, it would place all received packets into the latest buffer
address and add events to the event queue (if possible). I also added
a new routine to turn off the packet reception. A fifth approach would
be to have OURSL notice if the PostEvent failed, and if so, then
continue reading for a packet, otherwise, indicate that a packet has
been found (post the event) and start ignoring packets.  This last
approach requires that PostEvent return some kind of status code
saying if the event actually was posted -- although OURSL contains the
code for getting a return value as if PostEvent were a function, my
documentation for PostEvent shows it to be a procedure. (In any case,
OURSL throws away the return result).

Finally: has anyone moved the 68000 code for DDP from the Lisa to
the Sumac system (and changed the opcodes as appropriate - I think
this means getting rid of the '.'s before the size descriptions)?

			-Mark