Server-side Websocket implementations in non-event driven HTTP Server Environments

[unlinker]

I am trying to understand implementations/options for server-side Websocket endpoints - particularly in perl using PSGI/Plack and I have a question: Why are all server-side websocket implementations based around event-driven PSGI servers (Twiggy, Tatsumaki..etc.)?

I get that websocket communication is asynchronous, but a non-event driven PSGI server (say Starman) could spawn an asynchronous listener to handle the websocket side of things. I have seen (but not understood) PHP implementations of Websocket servers, so why cant the same be done with PSGI without having to change the server to an event driven one?

[Corion]

I think Mojolicious has a forking Websocket implementation in Mojo::Server::Daemon.

Personally, I like in-process Websockets, as I use them to communicate between clients. Usually I don't have an elaborate message queue schema set up, so distributing information is done easiest by keeping all clients connected to the same process. This is where AnyEvent comes in very handy for me.

[unlinker]

Thanks for responding. Could you explain "in-process websockets" please? Do you mean: there is a single process (same pid) that handles communication with all the connected clients? The documentation for Mojo::Server::Daemon lists it as a non-blocking server and has an event loop. How is that different from Twiggy and other event driven HTTP servers?

[Corion]

Yes, that's what I meant by "in-process websockets".

And it seems I misread Mojo::Server::Daemon then - it seems no different from Twiggy.

[Anonymous Monk]

AFAIK, http://cpansearch.perl.org/src/VTI/Protocol-WebSocket-0.12/examples/io-poll.pl and http://cpansearch.perl.org/src/VTI/Protocol-WebSocket-0.12/examples/reflex.pl are not event driven :) although I admit I might know what I'm talking about