Re: [hybi] #4: handshake does not work properly with HTTP reverse proxy.

["Shelby Moore" <[e-mail]>]

> Seems for WebSocket to be robust over HTTP ports (at least 80), we are
> going need to do handshaking on each data transfer, so am I correct that
> would eliminate most of the theoretical bandwidth and latency advantages
> over BOSH?

TCP does not solve this, because it is proxy driven failure, not a failure
of delivery between network nodes.

Correction, data corruption can be handled in one-direction with hash, and
for unknown timeouts (receiver does not know when data was sent) if we do
keep-alive (and also in headers of messages sent and received) then
server-client can communicate whether any messages were sent and not
received (eaten by the proxy).  So we don't have to handshake on each data
transfer.  Theoretically BOSH stochastically can achieve the effectively
same bandwidth, but BOSH will suffer twice the maximum latency (round-trip
versus one-way).  That maximum only occurs when BOSH has just sent a
message and needs to send another one in less time than one round-trip,
thus the average latency of BOSH will be less than twice that for
WebSocket? In non-constrained environments, more than 2 connections could
be used to reduce latency in BOSH?