Re: [hybi] Framing take IV

[Jamie Lokier <[e-mail]>]

Ian Hickson wrote:
> On Tue, 3 Aug 2010, Ian Fette (?~B??~B??~C??~C~U?~B??~C~C?~C~F?~B?) wrote:
> > 
> > For us it's the number of open sockets on the frontend, plain and 
> > simple. Each open socket == more kernel memory for socket buffers. 
> > Whereas, if we have multiplexing, I can take in a frame, see what stream 
> > it is, send it off to the appropriate backend and be done. Holding open 
> > multiple connections for a single user kills us.
> 
> We shouldn't design a protocol for the next few decades around a 
> limitation of a particular kernel implementation and how it affects one 
> particular deployment. Why don't we just change the kernel to send it off 
> to the appropriate backend and be done instead of using lots of kernel 
> memory for socket buffers?

Virtually all kernels handle sockets the same way.  Windows is a
notable exception.  WebSocket may or may not take over the world, but
it's still unlikely to matter enough to cause all major OSes to change
their kernels that much :-)

But anyway, it's a limitation of TCP, not particular kernels.

TCP requires, in practice, both ends to be able to buffer about the
same as the TCP window size, which must be large enough for reasonable
throughput.  The amount needed is getting larger as links get faster.
(Some links need gigabytes per socket, to get maximum sustained throughput!).

No kernel can avoid this, although good kernels reduce the average
memory used (allowing it to be used for caches), without reducing the
committed memory potentially used.

However let's not pretend multiplexing easily avoids this buffering.
While you can dispatch messages as they come in (with a single TCP
window's worth of buffer), you still need a comparable amount of
memory to buffer incoming *dispatched* messages in a general
implementation.

For example, browsers would buffer incoming WebSocket messages in the
DOM event queues, before they are processed by the independent
handlers of different WebSocket objects in different windows, perhaps
running in different processes (Chrome).  Those queues also use
comparable memory.

Servers will have equivalents to those queues, perhaps in pipes to
application processes or threads.

Although you can pick off one message at a time to dispatch and
process, before picking off the next one, and that *can* use much less
memory, that strategy breaks independence of flows, so it is not
usable as "transparent" form of multiplexing multiple processes over a
single socket.

Nonetheless, even though transparent multiplexing uses quite a bit of
memory too, the multiplexing way does give applications a lot more
control over buffering choices, including committing much less memory
to each flow than TCP would on a high bandwidth(-delay) link, while
maintaining efficient throughput on those links.

-- Jamie