On 11/28/12 2:22 PM, Danny Coward
Yes, you brought this up some time ago and we never resolved it.
As you point out doing an explicit test on the TCP connection is
expensive/unreliable. So I agree the notion of 'active' is not
What the websocket protocol does give us however is are the open
and close frames. I think its a useful concept for developers to
be able easily to list out the connections which the protocol
has notified have been opened, but have not notified that they
are closed. In other words, I think its going to be a very
common (and repetitive) pattern in server code to maintain a
list of such 'open' connections, even if they still need to code
around cases where one or two rogue connections have simply
vanished without telling anyone.
I'd propose we rephrase/name these API calls to be based on what
the websocket protocol gives us (open/close frames), which I
think addresses the expense/reliablity issue you bring up, which
relieving the developer of what I think is a common programming
I agree the spec should be written around close.
Because websockets is duplex, we do know if the connection closes,
because the read side will return as soon as the connection drops.
There's no need to test the write side.
On 11/26/12 1:00 PM, Bill Wigger wrote:
Sorry, I have another method
I would like to get rid of, or be enlightened about!
On the Session object is this
Return true if and only
if the underlying socket is open.
whether the session
What concerns me about this
call is the idea that one can easily tell if the socket is
open. Using the standard socket API available from the JDK
one cannot (at least I don't know how) in a straight forward
manner. This is because if the other side closed the
connection, then there is no notification given by the JDK
to any type of "socket close callback" or "listener". How
one finds out that a socket has been closed by the other
side is to do a Read or Write on the socket and get an error
or "EOF" back.
But if a Read or Write fails,
then the WebSocket user has already been notified. In the
case of the read/onMessage listener I'm assuming it is via
the EndPoint onError or OnClose method. In the case of a
write/send an IOException would be thrown.
So if the user is listening
for messages, or sending messages, then they will know right
away if the socket is no longer open. If the user is not
listening for messages nor sending messages, I don't know
how the server will be able to "poll" the connection to see
if it is active.
|| Danny Coward