Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)

[Willy Tarreau <[e-mail]>]

Hi Patrick,

On Tue, May 24, 2011 at 11:37:36PM -0400, Patrick McManus wrote:
> On Wed, 2011-05-25 at 12:08 +0900, Takeshi Yoshino wrote:
> 
> > . Yes, preparing something unpredictable solves this.
> 
> right, without further changes to the protocol. Then we could ship
> websockets and people could start writing applications instead of
> documents. Stability is a worthwhile goal.
> 
> > But this is interoperability problem between user-agents and servers
> > provided by various vendors/people
> 
> I disagree, because [see below]
> 
> >  enough, maybe I would use random bytes of 3 or more byte long.
> 
> right. The ping-generating-peer doesn't need cooperation from the other
> peer in order to create a unique payload. Interoperabiity does not
> require that each end use the same algorithm - either the client or the
> server can be the ping generating peer.

I would add that if one peer randomly sends pong messages, it's just
deliberately trying to get its communication degraded. Ping/pong may
be used in order to improve quality of service by detecting quickly
that a connection seems to be broken. There's nothing to win by fooling
this. It's similar to ICMP ping : instead of wondering what would happen
if Google sends me fake echo reply messages when I ping them to check if
my DSL line is OK, I prefer to ask why would they do this in the first
place and for what purpose ?

Here it's the same. We could similarly have peers that randomly send
crap just because it's fun, or send wrong size message on purpose, we
can imagine anything. It just has no use for the one sending that crap,
so basically I4d say that unsollicited pong messages must be ignored,
and that even if the other end fakes a perfect pong that you take for
valid, we should't care. This fake pong will lead to wrong RTT estimates
and the valid one will be ignored, end of the story.

In ICMP we have a sequence number in ping messages. This might be useful
to ensure we're getting the association right, and it's easier to recommend
using a counter than sending a random message. Some users might prefer to
send a timestamp in the message maybe.

Regards,
Willy