On Thu, 6 May 2010, Brian Hayden wrote:
TCP connections are more reliable than UDP; that does not mean they are "reliable", full stop.
You are using the wrong definition of reliable. Reliable does not mean "does not fail". UDP has no provision for reliability, ordering or data integrity. TCP does all of these. Regardless of what happens in the link layer, TCP delivers a sequential octet stream without duplication or missing data. The only thing that terminates that stream is a session disconnect. There is no such thing as "failure" in TCP. What you think of as being "failure" are all application layer concept: [1] The application received a session disconnect (FIN) from TCP. This is completely an application concept; TCP considers this to be a completely normal shutdown of the session. [2] The application received a session reset (RST) from TCP. This indicates that the application attempted to communicate with a TCP peer that does not exist. This is what most people (mistakenly) call a "TCP failure". [3] The application unilaterally decides that a failure has occurred. Now, [1] and [2] generally indicate the demise of the peer, with [1] being the normal and expected result of a mutually-agreed upon demise. [2] is not supposed to happen with debugged implementations, except when a link-level disconnect outlasts a FIN-wait. But neither of these are what the discussion is about. That is [3]:
TCP connections often do either fail completely or stall for so long as to constitute a failure
Now we come into myth vs. reality. Many people have observed that web browsers seem to fail or stall, and that hitting the refresh button seems to fix it. Because the web browser uses HTTP over TCP, they falsely conclude that this is an attribute of TCP and thus the equivalent of the refresh button is appropriate for other protocols. This conclusion is completely and utterly false; and is where stateful vs. stateless comes in. A web browser typically has multiple HTTP sessions in progress, each one of which is charged with resolving a different URI as these are encountered in the page. The whole idea is not to serialize the rendering of the web page; the fate of a JPEG being loaded is independent of any other piece. A web server, in turn, is obliged to turn around requests as quickly as possible. It poots data to the session and expects steady progress; otherwise it abandons the session. The browser is somewhat more patient but it too abandons the session if steady progress is not forthcoming. Now comes the important part: The server routinely abandons sessions, or refuses to initiate them, for load based reasons. This is alright, because HTTP is stateless and drops are expected in HTTP. There is no reason to believe that immediate retry will not succeed. IMAP, on the other hand, is a stateful protocol. A server does not drop IMAP sessions except under specification defined conditions: [a] The server received a TCP-level FIN or RST from the client. [b] Negotiated session disconnect (LOGOUT command). [c] Server crash. [d] 30 minute client inactivity timeout. If your IMAP connection "stalls", there is no reason to believe that disconnecting, creating a new connection, and retrying the operation will in any way help the situation. At best, it is a waste of effort; you destroyed your session state that now has to be rebuilt to get you back to where you were before. More typically, it is futile; the underlying problem impacts your new session just as your old session was impacted. As in the best case, you wasted effort; and now are worse off because you gave up all the data in your state which you could have used. In the worst case, it is harmful; not only is it futile, but it has also made a bad situation (e.g., server overload) worse. "But, but," you protest, "what if some router went out and came back up?" TCP recovers from that; or would recover if you let it. Please read up on the subject of TCP retransmissions and their algorithms including backoffs. These old guys who came up with TCP 30+ years ago knew what they were doing. Now, you may feel that the standard for TCP retransmission algorithms may need adjusting to reflect modern-day networking. You may be surprised to learn that I agree; and that the backoffs to avoid swamping the 56KB links on ARPAnet need updating for modern Ethernet and wireless link layers. So hop to it. Get involved with the standards development process. Do the experiments to work out what are suitable retransmission and backoff algorithms in the modern world. RFC 2988 is nearly 10 years old; and in particular sections 2.4 and 2.5 are probably completely obsolete and should be changed to something quite different. Don't duplicate TCP's functionality in the application layer (in a FAR less efficient and effective manner). Simple solutions to complex problems backfire. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Imap-uw mailing list [email protected] http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
