Don't track sockets in memory, or give option to track them not in-memory

[sontek]

If using multiple workers and long polling, you wont be able to track the sockets because they are tracked in memory per process.

We should track them via cookies or pluggable stores like redis.

[moodh]

Hello. Is there any news on this? Can I do something to help? I've tried with various methods but I believe I'm simply not proficient enough when it comes to sockets and network at this level.

Thanks!

[TronPaul]

Looking at the problem briefly it seems like if sockets on SocketIOServer had any dictionary like interface you could add default stores or make your own. Possibly define sockets's class to be dict by default and allow it to be set to whatever class you like as long as it's dictionary-like.

Possibly something like:

if 'socket_container' in kwargs:
    self.sockets = kwargs['socket_container']()
else:
    self.sockets = {}

Not sure if socket_container should be an object or a class.

[abourget]

Could we use the Manager in the multiprocessing lib ? On 2013-02-20 9:49 PM, "Mark McGuire" notifications@github.com wrote:

Looking at the problem briefly it seems like if sockets on SocketIOServerhad any dictionary like interface you could add default stores or make your own. Possibly define sockets's class to be dict by default and allow it to be set.

— Reply to this email directly or view it on GitHubhttps://github.com/abourget/gevent-socketio/issues/112#issuecomment-13870024.

[TronPaul]

I think that could work, especially as the default. Though making it easy to use a pluggable store or some other custom implementation would be nice. I'll try running tests against it.

Word of warning in that mutable objects inside a shared dict from Manager won't know if they've been modified or not, so to update them you need to reassign the object to the dictionary.

[moodh]

Hello, any news on this? We're planning on updating a huge site with socketio-gevent. Having to create multiple apps bound to different ports for IE to works feels like such an ugly workaround. :)

[sontek]

@moodh I'm looking into it this weekend but no guarantees

[jeromer]

Hi there, I started to work on a prototype to support a pluggable storage like Redis without breaking the current usage of dicts to work with sockets. You will find the code here : https://github.com/jeromer/gevent-socketio/commit/f2a90a253528b032163a976b1f6b58416f929193

The problem I am facing is that pickling the Socket object does not work because of the virtsocket.Socket.server.attribute. I am not sure about the correct way to pickle this object.

Do you have any idea/recommendation on how to pickle the Socket the right way ?

[dragozov]

Hi, I did some work on abstracting the sockets lifecycle management and getting multiple workers and xhr polling to work and implemented a Redis based solution in this fork: https://github.com/ryesoft/gevent-socketio/ From my testing so far it works well and I've been able to use both websockets and xhr polling across multiple workers using Django and Gunicorn. There is a sample Gunicorn configuration file based on what I use in the examples/django-gunicorn-redis folder