Re: [hybi] New port and Tunneling?

[Vladimir Katardjiev <[e-mail]>]

Just running this explanation (since I know it by heart already); I'll get to other points in due time.

On 17 aug 2010, at 08.44, Shelby Moore wrote:
>> I should also note that TCP doesn't guarantee delivery.
> 
> 
> Thanks for clarification.  What I meant is that TCP guarantees that we
> know when something wasn't delivered.  

No, it does not. You cannot prove the lack of existence of an event; you can only prove the existence of it. In other words, TCP can, in terms of the TCP stack itself, realise that a given packet has been delivered. It cannot realise that a given packet has been lost (it just assumes it is. This is why some packets are delivered twice). However, the TCP stack does not generally expose this functionality to upper layers. Namely, it's generally not possible for us as an application writer to ascertain that any given byte has been delivered. Since this means that even your garden variety TCP connection is not a stable transfer option, every application needs to assume that messages can and will be lost, and thus will have their own ACKs layered on top.
> 
>> This is exactly
>> the reason why WebSockets needs orderly close as part of the protocol
>> itself (because otherwise TCP may lose data).
> 
> I do not understand, because that is not my area of expertise (and my
> brain is tired and I am in a rush to send this and go do other things). If
> you are willing to explain, I am willing to read. Maybe most other readers
> understand what you mean.


Simply put, a client wishes to shut down. It needs to send a final piece of data to the server, and then close() the WebSocket connection. The client writes the bytes to be sent to the TCP output buffer, but then what? In the regular case, we can't ascertain when this buffer is empty. If we close the socket while the buffer is non-empty, we risk losing the data in it, depending on the implementation.

However, let's assume that the implementation will first send the bytes, wait for ACKs, then send the FIN to close the connection. Since TCP will ACK on /delivered/ and not /read/ bytes, this does not imply the remote application received them yet (it may be processing a different request). When the remote end receives the TCP FIN, it will close down the socket, and elicit EOF on it (because the socket is closed). The remote application can now not retrieve the data that was sent. 

For this reason, all HTTP servers leave TCP connections open for a certain timeout after a successful request has been answered, because otherwise the client might not get the entire page delivered. And for this reason WebSockets has an orderly close mechanism, to ensure that the data has been delivered before the connection is closed.

The reason I bring this up is because when you state that proxies break the guarantee of TCP, I state they don't. TCP never guarantees that data will be delivered. TCP guarantees the following:

Each byte read from the remote endpoint's socket will correspond to the same byte that was written in the local endpoint's socket. The bytes that arrive will arrive in the same order, and with no data corruption.

TCP also provides flow and congestion control, but these are minor in comparison.

What you likely refer to when you believe TCP guarantees delivery is the TCP retransmission mechanic. While a very good mechanic for a live stream, it does not guarantee you'll know where a transmission fails, only that it has failed. It's up to the application layer protocol to discover this failure and handle it. 

With that in mind, I hold that intermediaries can very well provide a similar level of service that plain TCP can. History has also shown that we're more likely to have intermediaries than not to, so I do not buy the argument that we're better off doing our best to tunnel/bypass/protect/disrupt them. Is it a compromise? Yes. But I believe it is a necessary compromise between those who wish to provide a new type of service and those who wish to manage their networks.

Cheers,
Vladimir