On 09.02.11 21:42, Jay McCarthy wrote:
2011/2/8 Jakub Piotr Cłapa<jpc...@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?
Yes.
I guess I will just catch the exceptions and clean everything up in the
handler. OTOH WebSockets should be able to be really long-lived. I guess
will look into it.
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?
I finally found time to try to do it but it looks like that although
there is a difference in the external text representation
(display/write), there is no tcp-closed? predicate. So no luck on this one.
--
regards,
Jakub Piotr Cłapa
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
