Peter Graf writes:

> >Yes, this I know, thanks... I'm perfectly aware of the fragmentation and
> >out of order receipt of TCP packets... That doesn't change the fact you
> >use the fast interrupt to store as many TCP packet as needed (i.e. when
> >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
> >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

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

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!


Reply via email to