Subject: [hybi] Hello frames?

From: Greg Wilkins <[email-masked]>
Date: Tue, 1 Mar 2011 08:25:28 +1100

Now the handshake is mostly settled, can we put Hello frames back on
the agenda to discuss. As has been discussed before, Hello frames can
be motivated for reasons other than the handshake or protecting from
attacks.

Specifically hello frames (or even just a mandatory ping/pong) can act
as a rapid test of the established WS channel, so we'd have a
conversation that looks like:

  --- client HTTP handshake -->
  <--- server HTTP handshake ---
  <--- server Hello (or ping) ---
  --- client Hello (or pong) -->

I'm happy with ping/pong if we are not going to have any meaningful
content to the packets.   However, if we want some meaningful content
that is different for client and server then either we need Hello
frames or we need to allow pongs to have different content to pings.

The content I would like to see in a hello is a description of the
timeouts and buffer sizes supported by the client/server.  One of the
big problems with Comet over HTTP is that we don't know what the
network times are, so we don't know what frequency we need to send
long polls.  The equivalent of this in websockets is how frequently
does a ping/pong need to be sent to avoid an idle close.   I
understand that a fair bit of work is needed to know who will send the
ping/pongs etc, but I think the first step in any plan will be
disclosure of timeouts.   Hello frames would look to be a good way
disclose this information.

cheers

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 28 Feb 2011 23:18:27 +0000

> The content I would like to see in a hello is a description of the timeouts and
> buffer sizes supported by the client/server.  One of the big problems with Comet
> over HTTP is that we don't know what the network times are, so we don't know
> what frequency we need to send long polls.  The equivalent of this in
> websockets is how frequently

[gab] Why would one side need to disclose timeouts to the other? Would a simpler approach work whereby either side would act on the timeouts by issuing a Ping at the appropriate time instead of disclosing the timeout. The other side's issuing a Pong would reset its timer (if it has not been sending anything else) and serves to suppress any Ping it would have otherwise sent.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 1 Mar 2011 12:27:34 +1100

> [gab] Why would one side need to disclose timeouts to the other? Would a simpler approach work whereby either side would act on the timeouts by issuing a Ping at the appropriate time instead of dis…

How does one side know what the appropriate time is?

If the server is configured with a  30s idle timeout, then the client
needs to know to send a ping every < 30s if it wants to keep the
connection alive.
Thus the server needs to disclose that timeout so the client can act on it.

Ideally, any intermediary would also append any timeouts it has to the
hello contents, so that timeouts can be known for the full path.   Of
course there is nothing to prevent a transparent proxy of NAT gateway
applying it's own timeout,   but I see that as no reason to give up
and not start declaring our timeouts and using those as the basis of
where to start our timeout at.

If we just give up and conceal our timeouts,  then I can see
ping/pongs being sent every 30s, which means that we will basically be
the same as long polling.

cheers

---

From: Justin Lee <[email-masked]>
Date: Mon, 28 Feb 2011 20:50:56 -0500

Why can't the *server* send those pings?  I had actually considered making
grizzly do just that in the absence of any clear direction one way or the
other in the spec.

On Mon, Feb 28, 2011 at 8:27 PM, Greg Wilkins <[email-masked]> wrote:

> > [gab] Why would one side need to disclose timeouts to the other? Would a
> simpler approach work whereby either side would act on the timeouts by
> issuing a Ping at the appropriate time instead of disclosing the timeout.
> The other side's issuing a Pong would reset its timer (if it has not been
> sending anything else) and serves to suppress any Ping it would have
> otherwise sent.
> >
>
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

-- 
You can find me on the net at:
http://antwerkz.com
http://www.linkedin.com/in/justinlee
http://www.twitter.com/evanchooly

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 1 Mar 2011 14:16:27 +1100

> grizzly do just that in the absence of any clear direction one way or the

Because it all depends on which end wants to keep the connection open.

Typically it will be the client that knows the user has the "chat
dialog" still open, so they know that the user wants to receive chat
and thus still needs the websocket connection.

Of course the client could tell the server with an ajax call and the
server side application could configure the server side to send pings
at some rate, but then after all that complication, the server would
not know the browsers timeouts and would still end up sending pings
more frequently than necessary.

As I said, there is some thinking needed to work out exactly who sends
the pings (application or infrastructure) and how applications
communicate to the whoever sends the pings if they want the connection
kept open or not..... Some of that consideration may involve the in
browser API and would need to be discussed elsewhere.      So
disclosing timeouts is not the end of the story, it's just a good
first step that may enable some more intelligent behaviour other than
sending frequent pings.

cheers

---

From: John Tamplin <[email-masked]>
Date: Mon, 28 Feb 2011 22:41:43 -0500

> first step that may enable some more intelligent behaviour other than

I really think if we are talking about keepalives and timeouts, this will
require much more effort to come to consensus on.  As an example of the
issues that arise -- if you are aggregating connections, whether in a
standard MUX extension or perhaps a vendor-specific tunnel, you probably
don't want to transport all the separate keep-alives across the channel, and
things like mobile implementations will want to put limits on what can be
chosen for keepalives for bandwidth and battery reasons.

I think it would be better to get the spec done with as few bells and
whistles as possible, and only then start working on things like specifying
keepalives.  Doing it right will probably also involve the application,
which means changing the JS API and yet more delay to get consensus across
groups.  If the application isn't involved, you will wind up having an
application-level keepalive on top of the channel keepalive and the ensuing
inefficiency.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 01 Mar 2011 13:10:27 +0900

On 2011/03/01 12:16, Greg Wilkins wrote:
> On 1 March 2011 12:50, Justin Lee<[email-masked]>  wrote:

Yes, but if that "chat dialog" isn't open anymore, the ping from the 
server won't be returned, and the server will know that it can close the 
connection. Or not?

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 1 Mar 2011 15:21:14 +1100

On 1 March 2011 14:41, John Tamplin <[email-masked]> wrote:
> require much more effort to come to consensus on.

True - which is why I'm not proposing any such thing at this time.

I'm simply saying that there is a case to have Hello frames, and that
it would be reasonable content for those frames to carry a declaration
of timeouts and buffer sizes.      This can form the basis of future
work on a standardized keep alive mechanism.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 1 Mar 2011 15:25:33 +1100

On 1 March 2011 15:10, "Martin J. Dürst" <[email-masked]> wrote:
> Yes, but if that "chat dialog" isn't open anymore, the ping from the server
> won't be returned, and the server will know that it can close the
> connection. Or not?

Sure, but having the server send the pings doesn't help.  It knows
it's own timeouts, but it does not know the browsers timeouts, so the
question remains - how frequently should the pings be sent.

Unless there is disclosure of timeouts, then any keep alive (at the
protocol or application level) will just have to guess a low value and
send frequent messages to keep the channel alive.

For example, the current implementation of cometd over websocket sends
exactly the same packet at the same frequency as the long polling
implementation (defaults to 30s).  Sure the ws data density is a bit
better, but the long poll is < MTU anyway, so their is not a lot of
difference between them for sporadic traffic profiles.

regards

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 1 Mar 2011 07:03:49 +0100

On Tue, Mar 01, 2011 at 12:27:34PM +1100, Greg Wilkins wrote:
> hello contents, so that timeouts can be known for the full path.

It could equally adjust the announced timeout to its own value if it's
lower. BTW I'd prefer to see a suggested heartbeat interval than a
timeout, because I can already imagine the number of situations where
client developers and server developers will fight considering that
the wrong timeout was announced. A suggested interval should be lower
than the timeout (typically half of the smallest one) and does not
look mandatory.

I'm even thinking that if we want to announce that, we'd better do that
in the initial HTTP handshake as a header, because it will be easy to
make any HTTP only intermediary add it or change it in the response.

That also means that it'd leave the ping usable for any purpose we
want :-)

Regards,
Willy

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 1 Mar 2011 17:15:52 +1100

On 1 March 2011 17:03, Willy Tarreau <[email-masked]> wrote:
> BTW I'd prefer to see a suggested heartbeat interval than a
> timeout,

work for me.

> in the initial HTTP handshake as a header,

Also fine with that

> That also means that it'd leave the ping usable for any purpose we

for a hello frame for example.

cheers

---

From: Andy Green <[email-masked]>
Date: Tue, 01 Mar 2011 07:30:46 +0000

On 03/01/2011 06:15 AM, Somebody in the thread at some point said:
> On 1 March 2011 17:03, Willy Tarreau<[email-masked]>  wrote:

Isn't it better to think of this as "idle timeout" for the channel?  If 
there's normal traffic coming from the other guy at any time, actually 
the receiver can take that as a PONG for a PING he didn't have to send 
and reset his idle timeout.  It's only after the channel is idle for the 
idle timeout he has to think about making synthetic traffic via PING to 
confirm all is still well.

>> in the initial HTTP handshake as a header,

That sounds like a good way.

> for a hello frame for example.

If you accept the idle timeout concept, in fact any traffic -- and 
someone is probably planning to send something when they set up the 
connection -- will serve as resetting the channel and explicit hello 
probing at the start isn't needed.

-Andy