TCP Urgent Pointer Usage

[N. Spiker]

I am attempting to receive a single TCP packet with some text ending with
carriage return and line feed characters. When the text is send and the
packet has the urgent flag set, the text read from the socket is missing the
last character (line feed). When the same text is sent without the urgent
flag set, all of the characters are read.

I'm reading the data using the blocking read call of the network stream
class. The .NET documentation does not discuss a special method needed to
support reading urgent data from a network stream.

I verified that in both cases the data is arriving correctly using a packet
sniffer (Ethereal). I also verified that both receiving and sending parties
are interpreting the urgent pointer according to the BSD implementation.

Is the urgent flag supported?

[Dave Sexton]

Hi N. Spiker,

From MSDN for OOB data:
Arrival of a TCP segment with the URG (for urgent) flag set indicates the
existence of a single byte of OOB data within the TCP data stream. The "OOB
data block is one byte in size. The urgent pointer is a positive offset from
the current sequence number in the TCP header that indicates the location of
the "OOB data block (ambiguously, as noted in the preceding). It might,
therefore, point to data that has not yet been received.

If SO_OOBINLINE is disabled (the default) when the TCP segment containing
the byte pointed to by the urgent pointer arrives, the OOB data block (one
byte) is removed from the data stream and buffered. If a subsequent TCP
segment arrives with the urgent flag set (and a new urgent pointer), the OOB
byte currently queued can be lost as it is replaced by the new OOB data
block (as occurs in Berkeley Software Distribution). It is never replaced in
the data stream, however.

With SO_OOBINLINE enabled, the urgent data remains in the data stream. As a
result, the OOB data block is never lost when a new TCP segment arrives
containing urgent data. The existing OOB data "mark" is updated to the new
position.

Link to article that contains info about OOB and non-OOB data flaged as
urgent; watch for wrapping:

http://msdn.microsoft.com/library/de...and_data_2.asp

HTH

"N. Spiker" <N. Sp****@discussions.microsoft.comwrote in message
news:DF**********************************@microsof t.com...

>I am attempting to receive a single TCP packet with some text ending with
carriage return and line feed characters. When the text is send and the
packet has the urgent flag set, the text read from the socket is missing
the
last character (line feed). When the same text is sent without the urgent
flag set, all of the characters are read.

I'm reading the data using the blocking read call of the network stream
class. The .NET documentation does not discuss a special method needed to
support reading urgent data from a network stream.

I verified that in both cases the data is arriving correctly using a
packet
sniffer (Ethereal). I also verified that both receiving and sending
parties
are interpreting the urgent pointer according to the BSD implementation.

Is the urgent flag supported?

[N. Spiker]

Dave,

In my test app I am not setting the SO_OOBINLINE socket option. Because of
this, the byte indicated by the urgent pointer field in the packet is
removed. In the app, I am reading the network stream using the class
NetworkStream (System.IO.Stream.NetworkStream) and the blocking read method.
Using this class, how would I read this removed byte of data or be notified
that an urgent byte of data is available?

As a follow-up, after reading the article you referenced, I am left
wondering whether the urgent flag is widely used. It appears that it would
not be. Is this an accurate statement?

Thanks again,
Nate

"Dave Sexton" wrote:

Hi N. Spiker,

From MSDN for OOB data:
Arrival of a TCP segment with the URG (for urgent) flag set indicates the
existence of a single byte of OOB data within the TCP data stream. The "OOB
data block is one byte in size. The urgent pointer is a positive offset from
the current sequence number in the TCP header that indicates the location of
the "OOB data block (ambiguously, as noted in the preceding). It might,
therefore, point to data that has not yet been received.

If SO_OOBINLINE is disabled (the default) when the TCP segment containing
the byte pointed to by the urgent pointer arrives, the OOB data block (one
byte) is removed from the data stream and buffered. If a subsequent TCP
segment arrives with the urgent flag set (and a new urgent pointer), the OOB
byte currently queued can be lost as it is replaced by the new OOB data
block (as occurs in Berkeley Software Distribution). It is never replaced in
the data stream, however.

With SO_OOBINLINE enabled, the urgent data remains in the data stream. As a
result, the OOB data block is never lost when a new TCP segment arrives
containing urgent data. The existing OOB data "mark" is updated to the new
position.

Link to article that contains info about OOB and non-OOB data flaged as
urgent; watch for wrapping:

http://msdn.microsoft.com/library/de...and_data_2.asp

HTH

"N. Spiker" <N. Sp****@discussions.microsoft.comwrote in message
news:DF**********************************@microsof t.com...

I am attempting to receive a single TCP packet with some text ending with
carriage return and line feed characters. When the text is send and the
packet has the urgent flag set, the text read from the socket is missing
the
last character (line feed). When the same text is sent without the urgent
flag set, all of the characters are read.

I'm reading the data using the blocking read call of the network stream
class. The .NET documentation does not discuss a special method needed to
support reading urgent data from a network stream.

I verified that in both cases the data is arriving correctly using a
packet
sniffer (Ethereal). I also verified that both receiving and sending
parties
are interpreting the urgent pointer according to the BSD implementation.

Is the urgent flag supported?

[Dave Sexton]

Hi N. Spiker,

Using this class, how would I read this removed byte of data or be
notified
that an urgent byte of data is available?

Try reading the out-of-band data using the managed Socket class by passing
SocketFlags.OutOfBand to one of the overloaded Socket.Read methods. You can
use Socket.Poll(timeout, SelectMode.Error) to detect the presence of OOB
data. (Note that you can specify Timeout.Infinite in place of the timeout
variable and Poll will block until OOB data is received)

As a follow-up, after reading the article you referenced, I am left
wondering whether the urgent flag is widely used. It appears that it
would
not be. Is this an accurate statement?

I'm not sure of its use, statistically speaking, but I am sure that
BsdUrgent flag does not provide something that you couldn't do without if
you have control over the source. In other words use proprietary encoding
or byte marks that you can detect while reading the stream to flag urgency
and transmit all data in-line so you don't have to worry about out-of-band
data, although OOB data could be used as well without the BsdUrgent flag.

HTH

"N. Spiker" <NS*****@discussions.microsoft.comwrote in message
news:04**********************************@microsof t.com...

Dave,

In my test app I am not setting the SO_OOBINLINE socket option. Because
of
this, the byte indicated by the urgent pointer field in the packet is
removed. In the app, I am reading the network stream using the class
NetworkStream (System.IO.Stream.NetworkStream) and the blocking read
method.
Using this class, how would I read this removed byte of data or be
notified
that an urgent byte of data is available?

As a follow-up, after reading the article you referenced, I am left
wondering whether the urgent flag is widely used. It appears that it
would
not be. Is this an accurate statement?

Thanks again,
Nate

"Dave Sexton" wrote:

>Hi N. Spiker,

From MSDN for OOB data:
Arrival of a TCP segment with the URG (for urgent) flag set indicates the
existence of a single byte of OOB data within the TCP data stream. The
"OOB
data block is one byte in size. The urgent pointer is a positive offset
from
the current sequence number in the TCP header that indicates the location
of
the "OOB data block (ambiguously, as noted in the preceding). It might,
therefore, point to data that has not yet been received.

If SO_OOBINLINE is disabled (the default) when the TCP segment containing
the byte pointed to by the urgent pointer arrives, the OOB data block
(one
byte) is removed from the data stream and buffered. If a subsequent TCP
segment arrives with the urgent flag set (and a new urgent pointer), the
OOB
byte currently queued can be lost as it is replaced by the new OOB data
block (as occurs in Berkeley Software Distribution). It is never replaced
in
the data stream, however.

With SO_OOBINLINE enabled, the urgent data remains in the data stream. As
a
result, the OOB data block is never lost when a new TCP segment arrives
containing urgent data. The existing OOB data "mark" is updated to the
new
position.

Link to article that contains info about OOB and non-OOB data flaged as
urgent; watch for wrapping:

http://msdn.microsoft.com/library/de...and_data_2.asp

HTH

"N. Spiker" <N. Sp****@discussions.microsoft.comwrote in message
news:DF**********************************@microso ft.com...

>I am attempting to receive a single TCP packet with some text ending
with
carriage return and line feed characters. When the text is send and
the
packet has the urgent flag set, the text read from the socket is
missing
the
last character (line feed). When the same text is sent without the
urgent
flag set, all of the characters are read.

I'm reading the data using the blocking read call of the network stream
class. The .NET documentation does not discuss a special method needed
to
support reading urgent data from a network stream.

I verified that in both cases the data is arriving correctly using a
packet
sniffer (Ethereal). I also verified that both receiving and sending
parties
are interpreting the urgent pointer according to the BSD
implementation.

Is the urgent flag supported?