>>> err... but... TCP urgent data aren't. That is, it is an urgent
>>> pointer, not urgent data, [...]

> from what I understand, urgent data pointer does provide out-of-band
> data processing (see stevens TCP/IP illustrated vol II, p 983).

If Stevens says the urgent pointer facility provides an out-of-band
data channel, then I'm sorry, Stevens is wrong.

Read RFC 793.  The urgent pointer marks a point in the data stream.  It
does not provide any way to tell how much of that data stream is
supposed to be out-of-band, nor, in the case of a second "out-of-band"
send before the first one has made it out on the wire, does it provide
any way to tell the first one even existed, much less where it was in
the data stream.

The BSD pseudo-OOB mechanism works acceptably provided you are using
low data rates compared to the throughput of the network between the
two machines.  This is mostly true between VAXen on an Ethernet (which,
not entirely coincidentally, is at least roughly the environment it was
developed in).  It can even be true on the global Internet if your data
rates are very low.  But if you have to care about the amount of data
queued to avoid exhausting the sending kernel's buffering capacity, it
is not true for you.

> not sure if it fits the originator's goal, but anyway, it is useful
> when you try to send ^C over telnet channel.

Read the telnet RFC; it _does_ understand that urgent data is not
out-of-band.  A telnet Synch-and-IP is in-band; the urgent pointer is
used only to advise the receiver that it would be Good to read stuff
ASAP, because there's something more important than routine traffic
coming up.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B