Hi vti,
I'm logging this here so that other PocketIO users can see the issue and what can be done to solve it.
Right now, objects that inherit from PocketIO::Pool can be supplied to PocketIO in order to support sharing $socket->broadcast and $socket->sockets messages across multiple instances. All that is needed is PocketIO->new(pool => $mypool), and PocketIO::Pool::Redis provides an example of how to do this. Once the changes in the room_support branch are cleaned up and merged, messages that $socket->broadcast->to('myroom') or $socket->sockets->in('myroom') will also use the Pool. In that branch, I proposed a single msg_send method on the Pool, since all those different possibilities are nearly identical from the Pool's point of view.
This works just fine for websocket and flashsocket transports. However, the other transports are physically split between their read end (a persistent HTTP connection) and their write end (an ephemeral GET or POST). This means, in the worst case, that a write request may be served by a PocketIO which doesn't host the corresponding read request. Architecturally, PocketIO assumes that a single Connection holds both read and write ends.
I would like to fix this by replacing the public write methods on the Connection with methods that indirect the write through the Pool. Then, a Pool can decide whether the connection is local and can be written immediately, or nonlocal and dispatched just like remote broadcasts/rooms/etc.
Once the room_support is merged and I see what you've done, I can try to work out the details of Pool-aware Connections, but if you have any advice on how the Connections (or something else entirely) need to be changed, I would greatly appreciate it.
Thanks, and much appreciation for the great code,
Michael.
Hi vti,
I'm logging this here so that other PocketIO users can see the issue and what can be done to solve it.
Right now, objects that inherit from PocketIO::Pool can be supplied to PocketIO in order to support sharing $socket->broadcast and $socket->sockets messages across multiple instances. All that is needed is PocketIO->new(pool => $mypool), and PocketIO::Pool::Redis provides an example of how to do this. Once the changes in the room_support branch are cleaned up and merged, messages that $socket->broadcast->to('myroom') or $socket->sockets->in('myroom') will also use the Pool. In that branch, I proposed a single msg_send method on the Pool, since all those different possibilities are nearly identical from the Pool's point of view.
This works just fine for websocket and flashsocket transports. However, the other transports are physically split between their read end (a persistent HTTP connection) and their write end (an ephemeral GET or POST). This means, in the worst case, that a write request may be served by a PocketIO which doesn't host the corresponding read request. Architecturally, PocketIO assumes that a single Connection holds both read and write ends.
I would like to fix this by replacing the public write methods on the Connection with methods that indirect the write through the Pool. Then, a Pool can decide whether the connection is local and can be written immediately, or nonlocal and dispatched just like remote broadcasts/rooms/etc.
Once the room_support is merged and I see what you've done, I can try to work out the details of Pool-aware Connections, but if you have any advice on how the Connections (or something else entirely) need to be changed, I would greatly appreciate it.
Thanks, and much appreciation for the great code,
Michael.