>> >> >> >> Jacob, the difference with your case is that this happens >> simultaneously >> >> for several (but not all!) clients. >> > >> > >> > Hi, i think that the highest priority (now) is giving better infos in >> the >> > error (at least the REMOTE_ADDR and the REQUEST_URI vars) >> > > Thank Roberto for the patch! > > Hi Igor, > I had an issue with this in one of my projects: > https://github.com/jrief/django-websocket-redis/issues/10 > After the PONG was missed, select() notified my code and then, after > flushing the websocket using uwsgi.websocket_recv_nb(), this resulted in > an > IOError. > I now just ignore that error; in some situations this helps when the > browser is unavailable for a short time, for instance, when the > screensaver > activates. > > As far as I understood, the server is responsible for sending PING, and > under normal conditions the browser then answers with PONG. In case the > browser looses connection without ever receiving a FIN package, the > browser > never sees the broken websocket and hence does not reestablish the > connection. > > One possible solution to this problem would be to have the browser send > some kind of PING packages himself, so that when they are unanswered, he > closes and tries to reestablish the connection. > > Roberto, is this a known issue, and/or is there any reference > implementation in Javascript to handle this problem?
Nope, and i really would like some form for of ping/pong starting from the client :( Currently (in 20tab, for gaming) we have started sending "heartbeats" from the server and instructed the client to close the connection if it does not receive one in the expected timeout. I think it is the only way to be sure you are still playing with the others :) -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
