Hi,

I think this question might be a simple one, but I did not find the RFC
793
clear in the matter: regarding out of order TCP segments, only those
segments
that contain data have to be reordered or others like FIN segments also
have to be ordered ?

RFC 793 generally puts the word data in the sentences where reorder
is in it like:

"
The TCP must recover from data that is damaged, lost, duplicated, or
delivered out of order by the internet communication system
"

or

" A stream of data sent on a TCP connection is delivered reliably and
in
order at the destination.
"

But in this other place it looks like all segments have to be
reordered:

"
A natural way to think about processing incoming segments is to
imagine that they are first tested for proper sequence number (i.e.,
that their contents lie in the range of the expected "receive window"
in the sequence number space) and then that they are generally queued
and processed in sequence number order.
"

Thanks

joseluismarchetti@yahoo.com.br wrote:
> I think this question might be a simple one, but I did not find the
> RFC 793 clear in the matter: regarding out of order TCP segments,
> only those segments that contain data have to be reordered or others
> like FIN segments also have to be ordered ?

The receiving application cannot be notified of the arrival of the FIN
until after it has been notified of the arrival of preceeding
data. (Similarly the FIN cannot be ACKed until all preceeding data has
arrived). That is to say, that everything in the TCP sequence space
is dealt with in order.

rick jones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

In article <1148687418.332913.258550@g10g2000cwb.googlegroups .com>,
joseluismarchetti@yahoo.com.br wrote:

> Hi,
>
> I think this question might be a simple one, but I did not find the RFC
> 793
> clear in the matter: regarding out of order TCP segments, only those
> segments
> that contain data have to be reordered or others like FIN segments also
> have to be ordered ?

SYN and FIN segments take up a byte of sequence number space, precisely
so that they can be fit into the proper order.

And if you process a FIN out of order, you'll end up missing the last
few data segments, which would clearly be wrong.

--
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 ***

Barry,

Interesting argument, at least if a packet changes the sequence number
it can be ordered.

Although I agree with you all that SYN and FIN, besides packets that
contains data have to be ordered, what are the places in RFC 793 that
this is stated ?

Thanks again

In article <1149016203.015314.144310@u72g2000cwu.googlegroups .com>,
joseluismarchetti@yahoo.com.br wrote:

> Although I agree with you all that SYN and FIN, besides packets that
> contains data have to be ordered, what are the places in RFC 793 that
> this is stated ?

Section 3.3 Sequence Numbers, page 26:

We have taken advantage of the numbering scheme to protect certain
control information as well. This is achieved by implicitly including
some control flags in the sequence space so they can be retransmitted
and acknowledged without confusion (i.e., one and only one copy of the
control will be acted upon). Control information is not physically
carried in the segment data space. Consequently, we must adopt rules
for implicitly assigning sequence numbers to control. The SYN and FIN
are the only controls requiring this protection, and these controls
are used only at connection opening and closing. For sequence number
purposes, the SYN is considered to occur before the first actual data
octet of the segment in which it occurs, while the FIN is considered
to occur after the last actual data octet in a segment in which it
occurs. The segment length (SEG.LEN) includes both data and sequence
space occupying controls. When a SYN is present then SEG.SEQ is the
sequence number of the SYN.

--
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 ***