info-mac@utcsrgv.UUCP (info-mac) (07/13/84)
Date: 12 Jul 84 1322 EDT (Thursday) From: uw-beaver!Mark.Sherman@CMU-CS-A.ARPA To: INFO-MAC@SUMEX-AIM.ARPA Subject: Suggested changes to the DDP interface of MPP 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