Out of band data

[Erik Naggum]

In article <483sis-d at massey.ac.nz>, Ajit Rasiah  writes:

   I am trying to use the out-of-band (OOB) facility of UNIX sockets.
   I tried a

	   send(s, "out of band data", 16, MSG_OOB);			[1]
	   write(s, "string 2", 8);					[2]

   When I perform a read() I get the string "out of band dat".

   It appears that the string "out of band dat" (note the missing last
   character) is considered low-priority, and the logical mark
   identifying the start of the urgent data is in fact the missing
   last character (the 'a'). This implies that the string "string 2"
   is actually the urgent data!

   Why is this? What I want, is to be able to read the urgent data
   separately from the low-priority without mixing them up. What is
   the best approach I should use?

I'm posting this to the group to air a suggestion.

The out of band facility was not intended to be used as a separate
data channel.  If you wish to multiplex two channels on one
connection, I suggest that you do something like this:

	#include <sys/types.h>
	#include <netinet/in.h>

	struct mux {
		u_short channel;
		u_short datalen;
	};								[1]

	int muxwrite (int fd, u_short channel, void *data, u_short count)
	{
		struct mux xmit;
		xmit.channel = htons (channel);
		xmit.datalen = htons (count);
		write (fd, &xmit, sizeof xmit);				[2]
		return write (fd, data, count);				[3]
	}

	int muxread (int fd, u_short *channel, void *data, u_short *count, u_short max_count)
	{
		struct mux recv;
		read (fd, &recv, sizeof recv);				[4]
		*channel = ntohs (recv.channel);
		*count = ntohs (recv.datalen);
		if (*count > maxcount)	{ }				[5]
		return read (fd, data, *count);				[6]
	}

NOTE: This is not anywhere near finished, polished code.  You need to
figure out how to deal with a failure of the write in [3] when the
write in [2] succeeded, because the read in [4] will expect a block of
data following the "protocol portion".  You would definitely do some
sanity checking on the received channel and datalen elements, etc.
There are problems to be solved in what you want to do when the test
in [5] succeeds.  There are also a few problems to be solved in what
to do if the return value of the read in [6] is less than what is
reported by *count.  It should probably loop, slurping up bytes until
the prescribed number of bytes are received.  A checksum could be
provided with [1].

You should probably devise a scheme by which these protocol portions
are introduced so that you can detect when or if screw-ups occur in
the protocol, e.g. by using a special magic value in [1] which is
allowed only at the head of the protocol data unit ("packet"), and
escaped when found in the data, much like SLIP does.

I think I have made an excellent argument against using only one
stream, and thus an equally excellent argument for two or more
streams, which you alternate between via the select(2) system call.
In fact, I suggest you do just that, instead of relying on long
strings of out of band data.

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik at naggum.uu.no>, <enag at ifi.uio.no>
My opinions.	Wail: +47-2-836-863	Another int'l standards dude.