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

[Salvatore Loreto <[e-mail]>]

<as individual contributor>

I agree with the fact that coordinating Ping and Pong body value assigment,
so that unsollicited Pong and reply Pong do not conflict each other,
should be clearly specified in the spec instead of leave this duty to 
the implementors or service designers.


More I share the concern Magnus has on the text in Section 4.5.2;
the text reduce significantly the possibility to develop future 
extensions based on ping/pong.
If people think that it is OK, I won't oppose, but I want to be sure 
that people are well aware of this fact.

    On 4/29/11 8:00 PM, Magnus Westerlund wrote:

    28. Section 4.5.2:

    The message
        bodies (i.e. both the Extension data (if any) and the Application
        data) of the Ping and Pong MUST be the same.

    I find the fact that the extension body data needs to be the same to be
    an issue. If one develops an extension that actually has to do with the
    frames and their transport then not being able to change the data will
    be an issue. As an example could be a Websocket RTT measurement
    extension where you like to include in the PONG both the PING sending
    time from the PING message and the amount of time between receving PING
    and sending PONG. Thus requiring one to add additional data.




-- 
Salvatore Loreto
www.sloreto.com


> (Detaching from TSV review thread)
>
> Greg,
>
> I see. Sounds ok to use assignment like that. As you said "it's over 
> reliable transport" in reply to my message, we don't need to use 
> sequence number as ping/ICMP does since there's no loss or reorder. 
> Maybe just \x00 (reply to ping) or \x01 (unsolicited) would be fine.
>
> Basically, I don't think it's good idea to make it duty of implementor 
> or service designer to choose body for Ping and unsolicited Pong 
> properly. That should be covered by the spec to reduce what to be 
> cared by user if possible. What do you think about specifying some 
> rule for the body strings to be used for Ping and unsolicited Pong in 
> the spec?
>
> - application data of Ping must start with \x00
> - application data of in-reply-to Pong MUST have the same body as the 
> received Ping
> - application data of unsolicited Pong must start with \x01
>
> I think the following is clearer.
>
> - when received Normal-Ping (Ping with its application data starting 
> with \x00), reply with Pong with the same body
> - when received NOP-Ping (Ping with its application data starting with 
> \x01), just ignore it
>
> On Fri, May 13, 2011 at 07:29, Greg Wilkins <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Takeshi,
>
>     what I have seen before is the use of sequence numbers where the
>     client side uses even and the server side uses odd, so can tell by the
>     seq number in a pong where it was generated and thus tell if it is a
>     response or unsolicited.
>
>     cheers
>
>
>     On 13 May 2011 04:36, Takeshi Yoshino <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >>   Obviously there is a chance that a unsolicited pong matches a
>     ping,
>     >> but some careful design of payloads can easily fix that.
>     >
>     > I see. Coordinating body value assignment so that unsolicited
>     one and reply
>     > one don't conflict each other (e.g. "ABC" and "XYZ" as you said)
>     is one
>     > possible solution.
>     > This should be discussed well when we add some keep alive
>     feature to browser
>     > that sends Ping to the server. If we prepare some API for
>     JavaScript to tell
>     > the browser what string to use for Ping, service designers may
>     coordinate
>     > assignment by themselves. If we don't, we should reserve some
>     string to be
>     > used for Ping/unsolicited Pong by browsers to avoid collision.
>     > ----
>     > Isn't it simpler to reserve some string, say "NOOP" (or "\x00"
>     to save
>     > bytes), for Ping body and require endpoints to ignore such Ping
>     rather than
>     > diverting Pong for heartbeat?
>     > Thanks,
>     > Takeshi
>
>