From: uxbqk@stud.uni-karlsruhe.de
Hi all,
the discussion is interesting :)
Am 8/10/2010 2:27 AM, schrieb Barry Margolin:
> In article,
> Rick Jones wrote:
>
>> Barry Margolin wrote:
>>> 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.
>>
i don't think that it should be a problem here. The client can send data
within its ACK but the server doesnt have to fork immediately a new
process after sending the SYN/ACK. He can firstly receive the ACK
packet, check the sequence number and ack number, if they are all
correct, he will then fork a process and handle the request data if
there is any there.
> What I was thinking about, though, was techniques like SYN cookies,
> which are used to deal with SYN-flood attacks. These wouldn't be
> effective if we considered the connection to be established as soon as
> we sent the SYN/ACK. What I find interesting is that people didn't
> think of these attacks until decades after TCP was designed, yet the
> architecture naturally allows for this deflection mechanism. One of the
> hallmarks of a good, general-purpose design is how well it allows for
> unanticipated features to be added on.
>
... and the SYN cookies technique is used just to avoid server saving
informations for those half-open connection.
I think, the problem here is similar in the 2-way situation.
In 2-way handshake, the server cannot know whether the client does
receive its SYN/ACK.
And the same situation in 3-way handshake, the client doesnt know
whether the server has received its ACK.
That means, when the last packet (SYN/ACK or ACK) gets lost, a system
might consider the connection to be established but the other one not.
Regards,
Effe
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
