Peter Graf writes: > >Yes, this I know, thanks... I'm perfectly aware of the fragmentation and of > >out of order receipt of TCP packets... That doesn't change the fact you could > >use the fast interrupt to store as many TCP packet as needed (i.e. when they > >come in), into a buffer (organized as a linked list of recieved packets), > >then to transfer the whole lot of packets to the higher level layers of the > >TCP/IP stack at once and every 1/50th of second... > > Obviously correct but useless. Try to understand that the problem in your > approach is latency and can not be solved by buffering, no matter how > efficient buffering is implemented. > > Simple example: A M$ or Unix machine sends a file to the QDOS machine via > TCP. It will send one or two packets, then stop and wait for ACK. Further > packets will only be sent after further ACKs. Your ACKs can only be > generated in 50 Hz rhythm, so packets will crawl one-by-one in 50 Hz > rhythm. (Or two-by-two, if you're lucky.)
But does the incoming data need to be processed in any way before acknowledgement? Why cant the ISR simply receive and buffer the data and then send the ACK before exiting, leaving any processing to the higher levels? In our January discussion you mentioned the case of echo. There is nothing to stop you from implementing time-critical routines, like echo, in the 'physical layer'. In fact you can take over the whole machine and do as you please. The important thing is to split the driver correctly: Time critical, ie usually hardware related stuff, and in this case it appears also certain demands of the TCP/IP protocol (if I understand correctly) are rightly the provinance of the ISR. If this sort of thing is not clearcut in TCP/IP, then a messy solution is called for ;) Arent you trying to make the OS do something it was never designed to do? Writing drivers is a programming challenge. The OS is there to help where it can, but no OS author can anticipate any and every piece of hardware that is going to be attached to the machine in the future. That is the job of the driver. (Preferably without each driver author altering the OS to suit their own needs ;) Afterall, someone did implement TCP/IP on the Spectrum, which neither multitasks nor (for all I know) understands interrupts. Good luck! Per
