Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sontek opened this issue Nov 26, 2012 · 8 comments
Open
Milestone

Comments

@sontek
Copy link
Collaborator

sontek commented Nov 26, 2012

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
Copy link

moodh commented Feb 6, 2013

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
Copy link
Contributor

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
Copy link
Owner

Could we use the Manager in the multiprocessing lib ?
On 2013-02-20 9:49 PM, "Mark McGuire" [email protected] 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//issues/112#issuecomment-13870024.

@TronPaul
Copy link
Contributor

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
Copy link

moodh commented Mar 10, 2013

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
Copy link
Collaborator Author

sontek commented Apr 13, 2013

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

@jeromer
Copy link

jeromer commented Jul 4, 2013

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants