daveb@rtech.UUCP (Dave Brower) (12/19/87)
Some people here have been trying to use the OOB mechanism to send
"expedited data" between processes. No one here is all that familiar
with using it, and they have run into some problems that make them want
to give up and turn to something else.
I'd appreciate hearing general thoughts about using the BSD oob
mechanism for IPC, and specific comments on the problems they report
below. I will forward responses to the interested parties.
Thanks!
-dB
------- forwarded message describing OOB headaches.
1. "Leapfrogging:" The fatal aspect of OOB data is that when two
socket sends for OOB data are issued in sequence before the first has
been read, the second send passes the first and is read out of
sequence by the recipient. This is a gross violation of the stream
socket abstraction and makes the mechanism fundamentally unusable
except in the simplest and most restricted cases, not the situation
here.
2. OOB receive loop: When an application has been notified of the
availability of OOB data and issues a receive for it, a subsequent
receive for normal data must be issued to "clear" the OOB notification
mechanism. If instead a select requesting notification of OOB data is
issued without an intervening receive for normal data, the caller is
immediately notified of the availability of OOB data: the same data
just received. This is at best a form of bizarre and undocumented
behavior; at worst a serious bug.
3. The integer-character problem: The IOCTL system call to determine
whether one has reached the OOB data in the stream is documented to
return a character. Several coding examples support this. In fact,
an integer is returned. It was necessary, after considerable grief,
to go to kernel source code to find that in fact an integer is
returned. It is not known how many similar major documentation errors
exist. Each could cause major delays, with time spent in fruitless
debugging.
--
"If it was easy, we'd hire someone cheaper than you to do it."
{amdahl, cbosgd, mtxinu, ptsfa, sun}!rtech!daveb daveb@rtech.uucp