Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!phoenix.Princeton.EDU!subbarao
From: subbarao@phoenix.Princeton.EDU (Kartik Subbarao)
Newsgroups: comp.unix.programmer
Subject: Re: inline OOB data with TCP sockets: why is it inserting extra byte?
Message-ID: <az8.BZxCGw6pM@idunno.Princeton.EDU>
Date: 28 May 91 17:12:41 GMT
References: <1991May18.021148.13730@athena.mit.edu>
Sender: news@idunno.Princeton.EDU
Reply-To: subbarao@phoenix.Princeton.EDU (Kartik Subbarao)
Distribution: usa
Organization: American Chemical Society
Lines: 63

In article <1991May18.021148.13730@athena.mit.edu> mlevin@jade.tufts.edu writes:
[lotsa code deleted]

>Now, the problem is this: it sort of works, but when the OOB data
>comes in, the sequence gets disrupted: it seems to insert en extra
>zero byte in the middle of it! Here's the output (of the reader):

[output deleted]

>As you can see, it somehow inserted a \0 between the 3 and the 4 in
>the string 1234 which I sent as a single OOB message. Where did it

It's not inserting a 0 anywhere. The read only returns 3, but since you 
ignore the return value of the read and print 4 things, the 4th one shows
up as a null because you bzero'd the array.

Remember, with sockets, read()s are not guaranteed to return the same
number of bytes that you request. I tried your program with a read that
checked to see how many bytes it got, but still had no luck fixing the
program. I then decided to get really basic and do this:

	  for (t = 0; t < 4; t++) {
	  	read(i, s+t, 1);
	  	ioctl(i, SIOCATMARK, &o);
      	if (o) printf("OOB: %c\n", s[t]);
   	  } 
	  if (!o) puts(s);
	}

i.e, read every single character and see whether its associated with either
Out of Band or a normal message. This is the output I got from running
this:

abcd
....
OOB:3
1234
abcd
....

So it would appear that the SIOCATMARK ioctl() only returned true when the
'3' was read. This consistently happens, which is kinda weird. I was under
the impression that SIOCATMARK would tell you whether the NEXT thing you
are going to read from the socket is OOB or not, but apparently it's the
other way around; you read something, then SIOCATMARK tells you whether it
was OOB or not. I'm not sure. What I don't see is (although I know read()s
aren't guaranteed to return the exact number of bytes you request) why
consistently the read is returning 3, and why the 4 somehow did not get
flagged as an OOB event. For that matter, why aren't the 1 and 2 being
flagged either? Either its quite strange, or I've really lost it.

I was thinking of approaching this problem from the different direction of
SIGURG or something? Would that work? And what's the deal here?


			-Kartik

--
internet% whoami

subbarao@phoenix.Princeton.EDU -| Internet
kartik@silvertone.Princeton.EDU (NeXT mail)  
SUBBARAO@PUCC.BITNET			          - Bitnet