Optional forked server application model

[markmaker]

Hi @Theldus,

very nice looking library, thank you for making it available. :1st_place_medal:

I'm in the course of evaluating libs and your approach with utter simplicity, but all the robustness is very convincing.

I'm looking into making the individual Websocket server workers into separate processes instead of threads, for various reasons, including robustness, security and (future) impersonation i.e. set_uid(). (Windows would be left out, as it does not support fork()).

The forked server model is described here (in my case it would not go through inetd but through a reverse proxy): https://www.ibm.com/docs/en/zos/3.1.0?topic=considerations-forked-server-application-model

Do you think wsServer would be a fit to implement the forked pattern?

I haven't yet studied the source much, but the following would have to be done (I guess):

1. fork() instead of creating a thread.
2. In the parent process, perhaps store the child pid in the client list, for some signalling.
3. In the parent process, close the websocket file handle, but don't tear it down.
4. In the child process, close all the other socket file handles, again without tearing anything down.
5. In the child process, stop the accept loop of the server, and prevent its tear-down when the child ends.
6. In the child process, handle just the one websocket until it closed, i.e. do the actual work, as you would in a thread.

I can always do this in a copy of the project, of course, but obviously, an integration using some #ifdefs would be better.

Any chance of you accepting a PR later? :sunglasses:

_Mark

[Theldus]

Hi @markmaker, Yes, what you've described is the classic approach of a server based on forks() instead of threads, and I believe it can be perfectly adapted for the wsServer.

However, I regret to say that I'm currently not interested in accepting PRs in that direction. The reason for this is that the current implementation with threads also bothers me. I plan to eventually move towards something based on polling multiple file descriptors, using methods like select(), poll(), epoll(), or some library. However, as this requires some code refactoring, I haven't tackled it yet.

[markmaker]

Hi @Theldus,

thanks for your answer, and I understand your different direction.

_Mark