I am writing a client/server application that involves many
network I/O over several devices and networks (TCP/IP, X.25
and serial lines, for instance). This application is dedicated
to work with very old, slow and low cost alphanumeric terminals,
which can receive data at a rate near 1000 bps.
The problem I will address soon is related to responsiveness.
Let's consider that the server is currently sending a screen
over a X.25 leased line, to a slow terminal at the other end.
The user, in from of his/her terminal, perfectly knows the
application and the page being sent; (s)he wants to immediately
go further, and strikes a key (say, validate, enter or something
like that).
A smart behavior would be the following: as soon as the server
receives the keystroke, its stops sending the screen data,
discards the pending packets from the write queue, then processes
the keystroke. This behavior is often named as anticipation.
If the server wouldn't discard the pending output buffers, the
terminal will keep on reading the rest of the screen and this
will prevent the server from sending other useful information
right after the keystroke.
The problem of anticipation is very easily solved with serial lines,
as you only have to make a TOCFLUSH ioctl. But this seems impossible
with sockets -- and the main use of my application is with X.25
sockets.
I've been looking around the kernel code, but couldn't find anything
like that. I'm quite sure it is feasible, though, if one takes care
of windows and ACK numbers.
I'm not aware enough with kernel hacking to do such a patch.
Does anyone see reasons why it would be infeasible/unsecure? I think
that discarding skbuff queues on demand would be a useful feature.
As a last resort, I want to be able to tell the kernel: "forget
anything about the data you received/sent, since my application-
level protocol says that I should start thinking of something
else right from now".
-- Paul Avisseau -- Aliénor Informatique -- http://www.alienor.fr Tél +33 (0)5 56 50 51 83 -- Fax +33 (0)5 56 39 70 16