Think about what's really happening. The RST is after the client acks
(if you actually took the time to look). I can serve 20% more clients in
the same time period (since we are talking about WEB servers). Open
your eyes and look at what's happening and its benefits rather that
pissing about the fact that some piece of code was not written robustly
enough to handle a procedure that is defined by the specification.
Note: Those nice guys who put the pretty butterfly on your web page were
the first guys to use this process and others followed.
Note: "Wrong" and "Stupid" is an attitude problem for software
developers. Creative, open minded and flexible attitudes would be more
helpful and productive.
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Pia Sahlberg
Sent: Friday, March 26, 2004 3:25 AM
To: ethereal-dev@xxxxxxxxxxxx
Subject: RE: [Ethereal-dev] TCP/IP Retransmission
>"wrong" and "stupid" are funny terms for open source developers to use
>when talking about someones efforts to improve performance (even if you
>do not agree with the procedures)...
lets clarify with an example:
It is wrong and stupid since it removes one of the nice features of TCP
:
reliability.
Without thinking an implementoir might think lets just RST the session
after i sent out the last segment to the other and performance will be
better than doing it the real way with FIN.
So he writes code that generates packets like :
Server->Client TCP last segment of the data pdu
Server->Client TCP RST
Now, will the server ever know if teh data was received reliably or
not?
Will it even work?
Think packet reordering. When the RST arrives to the client before the
data segment so the client kills the session before it has even received
the data it was waiting for.
Bad.
This can not happen if you close the session using FIN.
So essentially that implementation is now using unreliable tcp and no
one
can figure out why there are sometimes "issues" causing the client to
reissue the commands across a new session.
Worse, Server does not even know whether the client received the data or
not.
whats the point in using TCP if not to know whether the data arrived
safely
to the other end or not.
_________________________________________________________________
What's your house worth? Click here to find out:
http://www.ninemsn.realestate.com.au
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
____________________________
This email has been scanned.