Socket flush...

[Chris Torek]

(I stayed out of this because the original problem statement was not
accurate enough either to give a solution or to declare unsolvable.
Data buffering between communicating network peers occurs at several
levels, including the applications themselves, any kernel buffers, and
also data `in flight' on the wires.  The latter can be significant:  on
a transcontinental 100 Mb/s optical link in which the speed of `light'
is .9c, you can easily have 300 kilobytes of data stored in the optic
fiber alone.  This is a moderately significant amount, and it only goes
up as the transmission speeds increase and/or latency, typically in the
form of routers, is added.)

In article <1991Mar25.113452.6370 at athena.mit.edu> jik at athena.mit.edu
(Jonathan I. Kamens) writes:
>  Alas, I have never had to use out-of-band data, and as far as I can tell,
>the documentation on it is horrendously sparse, so I can't tell you how to do
>that (although I suspect that glancing through the sources to rlogin/rlogind
>and/or telnet/telnetd will give you hints).

The documentation is deliberately vague, for two reasons:  First, the
existing out-of-band mechanisms in Berkeley sockets are considered
`experimental', have changed several times, and may change again.
Perhaps more important in this case, TCP does not actually *have* out
of band data at all.  TCP has a concept called `urgent data' (which
differs from ISO/OSI `expedited data' in that TCP's is `urgent' while
ISO's is `expedited' :-) ) and the BSD `pull one byte out' trick is
nowhere near standard, unless you count de facto standards.

All in all, it is impossible to say what the right answer is, because,
as I noted above, the problem has not been pinned down.  In all
likelihood an attempt to state the problem exactly will lead to the
discovery that the problem is best solved by avoidance (choose a
different communications scheme).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov