[racket] WebSocket server dropping connections

From: Jay McCarthy (jay.mccarthy at gmail.com)
Date: Wed Feb 9 15:42:27 EST 2011

2011/2/8 Jakub Piotr Cłapa <jpc-ml at zenburn.net>:
> On 07.02.11 16:19, Jay McCarthy wrote:
>> I don't know much about Chrome 10, but is it possible that it has
>> dropped support for the old framing mode? The WebSocket implementation
>> supports both old and new, but defaults to old because that's what a
>> lot of browsers (used to) default to.
>> Look at framing-mode in the documentation.
> The connections work fine most of the time so I do not think this is a
> problem with handling of the protocol itself. Sorry, I should have been more
> explicit about this in my e-mail.
>> It is unlikely that they are being garbage collected, because it uses
>> the same "connection manager" machinery as the Web server, that
>> retains references to the ports.
> Does this machinery kill its threads without warning?

Yes, they have timeouts.

> Like shutting down the
> custodian after the tcp sockets get closed by the other end?


> After inspecting the source code for ws-closed? it also seams to me there is
> no way to find out if a websocket was closed but without proper handshake.
> Maybe ws-closed? should also check whether the underlaying sockets are open
> or the ws-send and ws-receive calls could change the ws-conn state on any
> tcp error?
> The problem can get magnified by the fact that AFAICT ws-close! will not be
> able to set ws-conn-closed? to #f if there are errors in the shutdown
> sequence (i.e. if write-byte throws an exception).

That sounds right... do you want to do patches/test cases?


> --
> regards,
> Jakub Piotr Cłapa

Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University

"The glory of God is Intelligence" - D&C 93

Posted on the users mailing list.