WebSocket Protocol

[Chris Boden]

I'm currently writing a PHP WebSocket library.  Components include an I/O server, WebSocket protocol, a Pub/Sub protocol (in dev), and various other small components (Logger, "Firewalls", etc).  I'm looking to replace my server component with something more robust.  I've come across AiP as it does/has so many things that interest me (Daemonize, LibEvent support, Session integration, lets Nginx handle I/O).

My question is, provided I implement a WebSocket protocol under \AiP\Protocol\WebSocket.php - could AiP handle long-lived full-duplex connections?

-- Some tech info to clarify that question --

WebSockets are an HTML5 implementation that is basically a TCP Socket over the HTTP port.  A client connection through JavaScript (for example) is established and stays open.  At any point the server or client can send information through this open connection.  There is no longer a request/response flow.  So, I'm wondering, can AiP keep a collection of established connections to, at any point, send/receive data without closing the connection?

[Alexey Zakhlestin]

On 08.01.2012, at 21:42, Chris Boden wrote:

> I'm currently writing a PHP WebSocket library. Components include an I/O server, WebSocket protocol, a Pub/Sub protocol (in dev), and various other small components (Logger, "Firewalls", etc). I'm looking to replace my server component with something more robust. I've come across AiP as it does/has so many things that interest me (Daemonize, LibEvent support, Session integration, lets Nginx handle I/O).
>
> My question is, provided I implement a WebSocket protocol under \AiP\Protocol\WebSocket.php - could AiP handle long-lived full-duplex connections?

I believe, that AiP won't be able to handle this. Currently, each connection is handled by separate process. So, keeping long-lived connections would mean, that you need same number of processes.
This will just kill any sane setup.

LibEvent mode could help with this, indeed, but it needs some love. It is a rough initial implementation which needs to be "fixed"

[Chris Boden]

Thanks for the quick response Alexey.  

My apologies, as I'm not quite an expert on this type of topic (pcntl, forking, threading), but could you help me better understand how AiP works?  My understanding is Nginx and AiP will run each as a single process with AiP loading a developer's code once.  A new connection comes in to Nginx, which creates a new thread on its one process.  Nginx hands the HTTP string to the running AiP process through a BSD socket...(this is where my knowledge becomes fuzzy) AiP forks itself, handles the request and sends it back to Nginx via a BSD socket?  Would this mean a new connection would copy the existing running developer application, duplicating memory consumption until it is closed?

What kind of love would your LibEvent implementation need?  I'm happy to learn more about AiP and contribute if I can.  I would much rather help you fix a problem and implement AiP on my project, if I can, instead of re-inventing the wheel.

[Alexey Zakhlestin]

On 08.01.2012, at 22:10, Chris Boden wrote:

> Thanks for the quick response Alexey.
>
> My apologies, as I'm not quite an expert on this type of topic (pcntl, forking, threading), but could you help me better understand how AiP works?

> My understanding is Nginx and AiP will run each as a single process with AiP loading a developer's code once.

Nginx is single-processed, but AiP is either single-processed or multi-processed (currently, number of workers is specified in config-file and equals "min" number always)

> A new connection comes in to Nginx, which creates a new thread on its one process. Nginx hands the HTTP string to the running AiP process through a BSD socket...(this is where my knowledge becomes fuzzy)

Nope. Nginx doesn't create threads. It gets request, forwards request to AiP and leaves connection "on hold" until new data comes from one of the sides, switching to the processing of the next request.

> AiP forks itself, handles the request and sends it back to Nginx via a BSD socket? Would this mean a new connection would copy the existing running developer application, duplicating memory consumption until it is closed?

AiP uses "pre fork" model, so one of the free running processes handles request (if none are free, request waits in queue).

> What kind of love would your LibEvent implementation need? I'm happy to learn more about AiP and contribute if I can. I would much rather help you fix a problem and implement AiP on my project, if I can, instead of re-inventing the wheel.

Well, proper support of libevent would mean that several requests can be handled by single process simultaneously.
I think, this can be achieved by some additional method in API, which allows applications to declare, that no more data is available right now and AiP/libevent should try to switch to the next request

Current approach of AiP is similar to Ruby Rack with all its limitations.

If you read Ruby, you can take a look at https://github.com/imanel/websocket-rack to get some inspiration on what has to be done