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

+1
I also see no purpose for correlating ping/pong data.  Or restricting the number of outstanding pings.  If you send 5 pings, you should expect 5 pongs, end of story.  The only real purpose for them is to see if the other end is still responsive, so send a ping and if you haven't gotten a pong after a certain user-decided timeout, close the connection.  It needs no further complication.

Brian

Sent from my iPhone

On May 18, 2011, at 12:07 PM, Piotr Kulaga <piotrku@microsoft.com> wrote:

> In my opinion, ping/pong frames should not carry application payload (foo and bar strings). If the payload is not well defined (i.e. reason, timestamp, etc.) there is no way the peer would understand how it should interpret the data. I would leave this problem the a protocol well-defined extensibility mechanism. If application wants to add payload to a ping/pong frame it should negotiate extension with the server and set a reserved bit on the frame. This way the basic protocol is simple and application can send/receive additional data if necessary (and negotiated).
> 
>  
> 
> I am ok with the 0x00 and 0x01 proposal.
> 
>  
> 
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gabriel Montenegro
> Sent: Tuesday, May 17, 2011 12:25 PM
> To: Takeshi Yoshino; hybi@ietf.org
> Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)
> 
>  
> 
> [As an individual]
> 
>  
> 
> I don’t think setting Ping/Pong as a platform for further applications is a good idea, for the same reasons that using ICMP as a platform for more intelligent applications is a good idea. Since ICMP does not follow the usual codepaths, any valid network characteristic measurements better not use, and they better use traffic that looks more closely like what an actual app would use (UDP, TCP). Similarly, I would expect Ping/Pong to not be treated as application traffic after network elements start being cognizant of Websockets. So the idea of using Ping/Pong for further apps doesn’t appear very convincing to me.
> 
>  
> 
> I’d much rather we kept Ping/Pong intentionally limited to its original purpose of just being a bare bones mechanism, and leave any other uses as proper extensions. 
> 
>  
> 
> The current text to say that only the last Ping need to be responded to discourages the peers from sending more than one, but it would be better to make it explicit that having more than one outstanding Ping (without its corresponding Pong) MUST NOT be done.
> 
>  
> 
> I think the 0x00 and 0x01 to distinguish unsolicited Pong is fine.
> 
>  
> 
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino
> Sent: Tuesday, May 17, 2011 04:03
> To: hybi@ietf.org
> Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07)
> 
>  
> 
> Full body matching requirement has been introduced by http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-03 for both close and ping/pong. What was the original goal of this requirement for ping/pong? Is it still valid? Full body matching requirement for close frames has been thrown away after long discussion.
> 
>  
> 
> Now it looks like it's sufficient to have single boolean to indicate it's nop or reply in application data.
> 
>  
> 
> Here's relaxed version.
> 
>  
> 
> foo and bar mean "any string"
> 
>  
> 
> a) implement heartbeat by diverting Pong
> 
> - Ping would be "Ping foo"
> 
> - to reply to "Ping foo", send "Pong \x00 bar" (bar is foo by default)
> 
> - to send unsolicited Pong, send "Pong \x01 bar"
> 
>  
> 
> b) implement heartbeat by diverting Ping
> 
> - to send Normal-Ping, send "Ping \x00 foo"
> 
> - to send NOP-Ping, send "Ping \x01 foo"
> 
> - to reply "Ping \x00 foo", send "Pong bar" (bar is foo by default)
> 
> - just ignore "Ping \x01 foo" when received
> 
>  
> 
> to adopt Bruce's idea, change "(bar is foo by default)" to "(bar is foo + buz)". it implements echo and allows the receiver to send additional info.
> 
>  
> 
> I've removed unnecessary \x00 and \x01, but it's fine for me to keep them to keep framing symmetric.
> 
>  
> 
> Takeshi
> 
>  
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi