support simultanious client connections

[ethanpailes]

Several people have brought up this feature as a nice thing to have. This could actually be somewhat tricky given shpool's existing architecture because of the way we have a per-session lock.

We may want to have a notion of readwrite sessions and readonly sessions the same way that abduco does.

[digitalsignalperson]

It's nice with e.g. screen multiple people can connect to the same session for troubleshooting / "CLI screenshare".

[ethanpailes]

Multiple people talking to the same shpool session may run into trouble because we currently protect against one user connecting to the daemon belonging to a different user to protect against priviledge escelation. I suppose we could add an off-by-default config option to allow this though.

[kflk]

What about the case of multiple cursors for live co-editing? You can see work by Zellij, Kitty, and Helix:

Share your Terminal with Multiple Cursors
https://zellij.dev/news/multiplayer-sessions/

Protocol extension: multiple cursors · Issue #720 · kovidgoyal/kitty
kovidgoyal/kitty#720

Something similar to VS Code Live Share · helix-editor/helix · Discussion #8568
helix-editor/helix#8568

[ethanpailes]

While supporting simultanious connections is a possibility for shpool, I don't think multiple cursors is in the cards. Merely mirroring sessions can be easily done in a shell-agnostic way, but multiple cursors would require knowing much more about how the inner shell works than shpool is able to know.

[hieubnt235]

Hi, I think this feature is the killer to completely replace tmux with kitty+shpool. Is this feature currently under development?

[ethanpailes]

No one is working on it right now as far as I'm aware. If you want to take a swing at it, I would be happy to drop some links to good starting points in the code.

[lawrencecchen]

I would be happy to drop some links to good starting points in the code.

Links would be great!

[ethanpailes]

Sorry I forgot to follow up with some links.

The main challenge of implementing this is that we store our shell constructs in a big table and each shell descriptor is wrapped in a mutex. When handling streaming traffic to a client process, we currently just hold that lock the entire time. In order to implement multi-client connections we would need to do some pretty significant reachtecture of the shell process management.

We currently keep the reader thread for shells around all the time and when a new cilent dials in, it just sends a message to that thread to register the new output file descriptor. For multicast streaming we would probably want to do something like that for the client->shell side of things as well, where we have a writer thread for the shell that just always sticks around and listens for new inputs coming in on a channel that it then just writes to the pty. The reader thread would also need to be updated so that it can handle fanning the output stream out to multiple clients at once.

[ethanpailes]

#363 is a request to add a third mode in addition to readwrite and readonly: readonly with immediate hangup. Seems pretty reasonable to implement all the same way.