"How does TCP handshake work?

1. Local device sends sequence number and maximum segment size.
2. Destination device responds by sending its sequence number and maximum
segment size back to local device.
3. Local device acknowledges receipt of the sequence number and segment size
information."

What're "sequence number and maximum segment size" in the above?

"webfan" <webfan@yahoo.com> wrote in message
news:HOIUg.186934$QM6.97097@bgtnsc05-news.ops.worldnet.att.net...
> "How does TCP handshake work?
>
> 1. Local device sends sequence number and maximum segment size.
> 2. Destination device responds by sending its sequence number and maximum
> segment size back to local device.
> 3. Local device acknowledges receipt of the sequence number and segment
size
> information."
>
> What're "sequence number and maximum segment size" in the above?

A sequence number is a 32 bit number. TCP will pick a random sequence number
as the initial sequence number in a TCP connection. these numbers are
clocked at a 4us rate, hence it will take over 4 hours to count through each
possible number using a 32bit word.

Maximum segment size is maximum amount of data allowed in a segment, not
counting headers. So your segment can actually be larger than the MSS when
you add up the headers

Or from RFC 879

THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS
FORTY.

The default IP Maximum Datagram Size is 576.
The default TCP Maximum Segment Size is 536.


>
>

"Dana" <raff242@yahoo.com> writes:

>A sequence number is a 32 bit number. TCP will pick a random sequence number
>as the initial sequence number in a TCP connection. these numbers are
>clocked at a 4us rate, hence it will take over 4 hours to count through each
>possible number using a 32bit word.

What does "clocked at a 4us rate" mean here? If it's initial sequence
numbers, they're supposed to be random (though they weren't) and they're
no longer "clocked".

For existing connections it's clocked at the data rate. (And Gbit ethernet
could theoretically wrap this in under 40 seconds)


Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Dana <raff242@yahoo.com> wrote in message
news:12i6ouddk9fso8d@corp.supernews.com...
> "webfan" <webfan@yahoo.com> wrote in message
> news:HOIUg.186934$QM6.97097@bgtnsc05-news.ops.worldnet.att.net...
> > "How does TCP handshake work?
> >
> > 1. Local device sends sequence number and maximum segment size.
> > 2. Destination device responds by sending its sequence number and
maximum
> > segment size back to local device.
> > 3. Local device acknowledges receipt of the sequence number and segment
> size
> > information."
> >
> > What're "sequence number and maximum segment size" in the above?
>
> A sequence number is a 32 bit number. TCP will pick a random sequence
number
> as the initial sequence number in a TCP connection. these numbers are
> clocked at a 4us rate, hence it will take over 4 hours to count through
each
> possible number using a 32bit word.
>
> Maximum segment size is maximum amount of data allowed in a segment, not
> counting headers. So your segment can actually be larger than the MSS
when
> you add up the headers
>
> Or from RFC 879
>
> THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS
> FORTY.
>
> The default IP Maximum Datagram Size is 576.
> The default TCP Maximum Segment Size is 536.
>
>

Thanks!

So the handshake of TCP is "simply":
1. A sends "A random sequence number + 536"
2. B responds with "the same sequence number as in 1 + 536"
3. A responds with ACK to B

Is this basically correct?

What does this accomplish anyway?

webfan <webfan@yahoo.com> wrote:
> Thanks!

> So the handshake of TCP is "simply":
> 1. A sends "A random sequence number + 536"

No. The SYN will contain an ISN (Initial Sequence Number) and then
there may be an optional MSS advertisement. If there is no MSS option
in the SYN the SPEC says one should assume 536.

> 2. B responds with "the same sequence number as in 1 + 536"

B will ACK A's ISN and will send its own ISN which will be different
from A's.

> 3. A responds with ACK to B

Correct.

> Is this basically correct?

> What does this accomplish anyway?

The two sides know at what point in the sequence space data transfer
starts so they know which sequence numbers will be "in the window" and
thus valid at a given point in time, and which are not and should be
ignored. That, combined with the TIME_WAIT state will protect a new
TCP connection from accepting as valid old segments from a previous
TCP connection of the same "name." (local/remote ports and
local/remote IPs)

The switch to random ISNs was prompted by security concerns that those
wishing to spoof would be able to guess the next TCP ISN a TCP would
use and so be abel to impersonate that TCP. From a practical
standpoint, it also meant it was no longer likely to have a successful
early transition from TIME_WAIT to ESTABLISHED because the ISN for the
new connection would not be in the right place relative to where that
connection name last left-off.

rick jones
--
a wide gulf separates "what if" from "if only"
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...

"Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
news:45237860$0$4528$e4fe514c@news.xs4all.nl...
> "Dana" <raff242@yahoo.com> writes:
>
> >A sequence number is a 32 bit number. TCP will pick a random sequence
number
> >as the initial sequence number in a TCP connection. these numbers are
> >clocked at a 4us rate, hence it will take over 4 hours to count through
each
> >possible number using a 32bit word.
>
> What does "clocked at a 4us rate" mean here? If it's initial sequence
> numbers, they're supposed to be random (though they weren't) and they're
> no longer "clocked".
>
> For existing connections it's clocked at the data rate. (And Gbit
ethernet
> could theoretically wrap this in under 40 seconds)

Thanks for the correction. My older book used the slower clock speeds in
existance.
On one sentence you say they are no longer clocked, the next sentence you
say they are clocked at the data rate, can you offer some clarification.


>
>
> Casper
> --
> Expressed in this posting are my opinions. They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.