t-delegated.example.com> 5d6cbc59
d088e0b0
From: barmar@alum.mit.edu
In article
,
David Schwartz wrote:
> On Aug 6, 10:40 am, Effe wrote:
>
> > i'm learning TCP and have a question about the 3-way-handshake used to
> > establish a TCP connection...
> >
> > Why can't we use a 2-way-handshake to establish a connection?
>
> How would the second side know that the connection was actually
> established?
>
> > I knew that with 3-way-handshake TCP can solve the problem when an old
> > SYN packet arrives before the actual SYN arrives (duplicate SYNs).
> >
> > But although there's a problem, which 3-way-handshake also can not
> > solve, isn't it?
>
> 1) Side A sends a SYN. It contains negotiation flags and other
> information.
>
> 2) Side B receives the SYN. The replies with negotiation flags and
> other information.
>
> The reply may get through or it may be dropped. As far as side B
> knows, side A may or may not have gotten the negotiation information
> and critical session establishment information. How can side B
> consider the session established at this point?
If A doesn't receive the SYN/ACK, it will resend the SYN. If it does
receive it, it can include the acknowledgement of the SYN/ACK with the
next segment it sends (perhaps the first data segment).
The main problem with this is that it requires the server to reserve
resources for the connection (e.g. fork a server process) before it's
sure that the connection has been established. If all application
protocols required the client to send a data segment first, we could use
that as the 3rd step in the handshake. But there are many protocols
where the server sends the first data segment (e.g. in SMTP, the server
sends a greeting message).
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
