[Libwebsockets] multiple connections to shared worker process
andy at warmcat.com
Sat Jul 8 10:15:11 CEST 2017
On 07/07/2017 01:35 PM, Per Bothner wrote:
> I recently implemented support for multiple panes and tabs in DomTerm:
> It's pretty neat - please check it out.
> To "complete" the functionality of screen/tmux I need add session
> That means decoupling the websocket connection (to the browser) from the
> pty worker process.
> Currently, the worker process has its own wsi (used for polling
> of pty output) and that wsi's parent is the websocket wsi.
> However, I believe we need to invert this: A pty process
> may be attached to multiple websocket connections (if, for example,
> multiple users are connected to the same screen). In that case
> output from the pty needs to be sent to each websocket client.
> A pty process may also be connected to zero websocket connections,
> corresponding to a detached session.
I'm not sure it's exactly inverting it.
The point seems that you may have "headless" sessions, and you may have
sessions with multiple ws consumers bound to them. So it's more a
> I've started splitting up the data structures to support this. So far
> so good,
> but I expect I'll have some questions once I actually attempt multiple
> connections per pty.
> Any advice? Is there example code for how to do this? For example a
> chat/mud server based on lws would be helpful.
Mirror was always a good example. I pushed a patch on master showing
what I think is best practice for the generic part of what you want...
mirror works as before but if you provide ?mirror=name on the URL
loading the test server HTML, it creates a new instance of the mirror
sharing FIFO only for guys who had the same ?mirror=name name. Guys
connected with a different mirror name (without any given, it's "") are
unaffected. By default it continues to work as before with everyone
joining the same "" mirror instance.
This sounds facile but actually the implementation shows how to maintain
a linked-list of wsi that are on the same name, and send requests for
writable only to those efficiently.
The linked-list for who is bound to what is done in the pss. Unless you
find you need something new in the library I'd recommend at least
considering this method, it's scaleable, lightweight and very fast to
More information about the Libwebsockets