peter@sersun0.essex.ac.uk (Allott P) (12/22/89)
We have "discovered" an apparent limit of 1 byte for the length of OUT OF BAND messages. We are using Sun-os 4, but have the strong feeling that this is much more general. The "sends" appear to work but the "recv" only gives one byte as being received, and should more than one byte have been sent, then the byte received appears to be garbage. Can anyone explain why? Also suggestions of work rounds would be appreciated, we need a method of reporting fatal errors over an active link.
chris@mimsy.umd.edu (Chris Torek) (12/23/89)
In article <2773@servax0.essex.ac.uk> peter@sersun0.essex.ac.uk (Allott P) writes: >We have "discovered" an apparent limit of 1 byte for the length of OUT OF >BAND messages. (What, for loud out of band messages? :-) ) >We are using Sun-os 4, but have the strong feeling that this is much >more general. It certainly is. TCP does not *have* out of band messages. It has, instead, `urgent data'. Those who implemented 4.2BSD (you know who you are :-) ) chose to treat the first byte of a region marked `urgent' as `out of band' data. It is not, really---in fact, there is no way to tell exactly which bytes the urgent pointer really points to---but this interpretation is as wide-spread as 4.2BSD and TCP systems derived therefrom. (Almost all Unix TCP implementations are 4.2BSD-based, and even many VMS TCPs have the same ultimate origin.) XNS *does* have out of band messages. They are one byte long. Network protocols that have out of band messages typically restrict them to one (or a few) bytes. This, of course, is the reason for the 4BSD interpretation. >... suggestions of work rounds would be appreciated, we need a method of >reporting fatal errors over an active link. (a) use a separate socket; (b) report failure in-band (wrap a protocol on top of TCP). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris