Subject: [hybi] WS & Nagle in use

From: "Greg Longtin" <[email-masked]>
Date: Mon, 21 Mar 2011 08:19:03 -0500

To all,

Good day.  Previously, I asked that WS should disable Nagle, or the API
might allow control of it.  This weekend I thought of the converse.

Not being familiar with all OS's, I'm not sure if, now or in the future,
administrative control may affect whether Nagle can be controlled at an app
level.

Hence, should the specs state clearly that if a server or client WS
application receives a 'multiple message' Nagle packet, that all messages
should be decoded from it?

In my testing, I'm not sure if the current clients did so.  Should I test
the Minefield and Silverlight implementations, or are we certain that they
do so?
 
Thanks,

Greg

---

From: Andy Green <[email-masked]>
Date: Mon, 21 Mar 2011 13:29:32 +0000

On 03/21/2011 01:19 PM, Somebody in the thread at some point said:

Hi -

> should be decoded from it?

I think it must handle this anyway because some other box between you 
and the client might choose to batch them up into a single packet for 
whatever reason.

> the Minefield and Silverlight implementations, or are we certain that they

libwebsockets does handle the whole parsing bytewise without reference 
to packet boundaries, but we had a user that found some windows machines 
triggered this 5Hz nagling business.  Everything continued to work on 
other clients at the same time and even on those nagled clients, just 
the latency turned to crap for them.

-Andy

---

From: Patrick McManus <[email-masked]>
Date: Mon, 21 Mar 2011 09:34:22 -0400

> should be decoded from it?

TCP is a byte stream protocol - a single WS message might span multiple
tcp packets with just 1 data byte in each, or it might be carried with
thousands of other WS messages in a single TCP segment which itself is
fragmented across multiple IP packets.  Or of course there might be 1
websocket message per TCP segment.

Websockets cannot restrict those options in any way, and receivers must
deal with it (firefox included, because you asked.). The TCP API is
bytestream based - it doesn't give reliable insight into how the data
was arranged when it arrived.

That doesn't really have much to do with nagle. You might see coalescing
due to TCP congestion control delays or network driver scheduling delays
or any number of other various indeterminate things.