Hello

If an application is using read() instead of recv() on a TCP socket ,
what happens if some out of band data is sent? Does read() just read
it in as normal data or is it stored away elsewhere and only be
recovered using one of the recv*() functions?

Thanks for any help

B2003

[ Post a follow-up to this message ]

> If an application is using read() instead of recv() on a TCP socket ,
> what happens if some out of band data is sent? Does read() just read
> it in as normal data or is it stored away elsewhere and only be
> recovered using one of the recv*() functions?

To my knowledge, TCP has no mechanism to transport
"out-of-band" data.

TCP has an "urgent-mode" that is, a part ot the
transmitted data can be marked as urgent. The
reaction on the arrival of such data is depending on
the receiving process. It can ...

... read all data before the urgent data and store it for later
processing ... read and process the urgent data ... process
the stored data ... continue with normal processing

... read and drop all data before the urgent data ...
process the urgent data ... continue with normal
processing

... ignore the fact that some data is urgent completely
and just treat all data as normal.

But the process cannot read the urgent-data out of sequence.

[ Post a follow-up to this message ]

In article <f7526c$pcn$1@daniel-new.mch.sbs.de>,
Rainer Temme <Rainer_Temme@nospam.hotmail_dot_com> wrote:
 
>
> To my knowledge, TCP has no mechanism to transport
> "out-of-band" data.
>
> TCP has an "urgent-mode" that is, a part ot the
> transmitted data can be marked as urgent. The
> reaction on the arrival of such data is depending on
> the receiving process. It can ...

True, but the sockets API automatically treats the byte that the urgent
pointer points to as OOB data.

>
> ... read all data before the urgent data and store it for later
> processing ... read and process the urgent data ... process
> the stored data ... continue with normal processing

Which is what the sockets API does.

> ... read and drop all data before the urgent data ...
> process the urgent data ... continue with normal
> processing

AFAIK, the sockets API doesn't provide any way for an application to do
this, because you don't get access to the urgent pointer itself.

> ... ignore the fact that some data is urgent completely
> and just treat all data as normal.
>
> But the process cannot read the urgent-data out of sequence.

The OP's question was: what happens to the byte that the urgent pointer
points to if you use the standard Unix stream API (i.e. read()) rather
than the sockets API (recv()).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

[ Post a follow-up to this message ]

On Jul 12, 7:45 pm, Barry Margolin <bar...@alum.mit.edu> wrote:
> In article <f7526c$pc...@daniel-new.mch.sbs.de>,
>  Rainer Temme <Rainer_Te...@nospam.hotmail_dot_com> wrote:
> 

By default, the sockets API does not permit the OOB data to be read
via read().  You have to use a recv* function with the MSG_OOB flag.
That can be changed using the SO_OOBINLINE socket option.  I strongly
advise you to go read chapter 21 of W. Richard Stevens's "UNIX Network
Programming, volume 1: Networking APIs: Sockets and XTI", wherein all
the details are discussed and demonstrated.


...[vbcol=seagreen] 
>
> Which is what the sockets API does.

Uh, are you really saying that the socket's API stores the normal data
that came before the urgent data and delivers it after the urgent
data?  Rainer was saying that the *application* can do that.

 
>
> AFAIK, the sockets API doesn't provide any way for an
> application to do this, because you don't get access to the
> urgent pointer itself.

Using the SIOCCATMARK ioctl(), the application can determine whether
the read position is at the urgent pointer.  Note that the read
position will never 'skip over' the urgent pointer, as read() will
return less than requested rather than do that.  (Some newer systems
provide a sockatmark() function to do this, as specified by the Single
Unix Spec, but it isn't as widely implemented as the ioctl(), so
you're better off with the ioctl(), at least for now.)

Alternatively, the application can try to read the OOB data using
recv() with the MSG_OOB flag: if the data hasn't arrived yet then
it'll return EWOULDBLOCK.  The application can read (and either toss
or save) another buffer's worth of normal data and then try again.

[vbcol=seagreen] 

And note that it can either ignore the data by treating it as normal
(by setting the SO_OOBINLINE socket option) or by never reading it
from the kernel's OOB buffer.


Philip Guenther

[ Post a follow-up to this message ]