WebSocket Close

#1

Hi - We are facing an issue where the websocket connection stops responding after being idle for some time. As a workaround, we implemented a ping mechanism where we ping the server every X mins.

But now with this frequent connects and disconnect , the sockets are piling up on the server.

Question -

  1. Do we as a client close the connection ? The autobahn java client lib does not give any method other than disconnect(). Is it ok to use this ?

  2. Who should initiate the close control frame ? The client or the server ?

Thanks,
Kanwar

···
0 Likes

#2

Hi, sorry for delay .. was totally overloaded recently.

Hi - We are facing an issue where the websocket connection stops
responding after being idle for some time. As a workaround, we
implemented a ping mechanism where we ping the server every X mins.

Keeping WebSocket connections "alive", especially on mobile networks, can be a challenge. There are many aspects .. ping/pong every couple
of minutes might not be enough.

But now with this frequent connects and disconnect , the sockets are
piling up on the server.

Question -

1) Do we as a client close the connection ? The autobahn java client lib
does not give any method other than disconnect(). Is it ok to use this ?

Yes. Calling disconnect() will perform a proper WebSocket closing handshake.

2) Who should initiate the close control frame ? The client or the server ?

As you like. With WebSocket, both peers are allowed to initiate a closing handshake.

···

Am 30.06.2012 19:38, schrieb sangha:

Thanks,
Kanwar

0 Likes

#3

Hi - Over the mobile data network , there is flakiness and when i call close(), the following is the issue -

In WebSocketReader, run() is waiting on a blocking socket call -

public void run() {

  if (DEBUG) Log.d(TAG, "running");

  MMLogger.logInfo(MMLogger.LOG_TAG, "Inside WebSocketReader()");
  try {

     mFrameBuffer.clear();
     do {
         
         //MMLogger.logInfo(MMLogger.LOG_TAG, "Inside WebSocketReader While loop()....mStopped is == " + mStopped);
        // blocking read on socket
        int len = mSocket.read(mFrameBuffer);

and in WebSocketConnection when we fail the connection, it tires to call quit() method in WebSocketReader(), which sets the mStopped to true but the read call is blocked since the socket over mobile data n/w has gone to a
inconsistent state. The Join() never returns from the call in failConnection() and we see multiple instances of reader and writer threads running + onClose() never gets called.

if (mReader != null) {

          mReader.quit();

          try {

             mReader.join();

          } catch (InterruptedException e) {

             if (DEBUG) e.printStackTrace();

          }

          //mReader = null;

       } else {

          if (DEBUG) Log.d(TAG, "mReader already NULL");

       }

To workaround the issue - I have closed the input stream in quit() . This seems to be working fine…

public void quit() {

  mStopped = true;

  MMLogger.logInfo(MMLogger.LOG_TAG, "Inside WebSocketReader quit(). mStopped is set to == " + mStopped);

  // this was causing the thread to hang since there is a blocking call in run which never comes out if there is ungraceful close()
  // as a workaround - we close the input stream to wake that thread up so that can be closed properly
  try {
    mSocket.socket().shutdownInput();
} catch (IOException e) {
    // TODO Auto-generated catch block
    e.printStackTrace();
}
 
  if (DEBUG) Log.d(TAG, "quit");

}

Is this OK ??

···

On Sunday, July 8, 2012 10:04:46 AM UTC-5, Tobias Oberstein wrote:

Hi, sorry for delay … was totally overloaded recently.

Am 30.06.2012 19:38, schrieb sangha:

Hi - We are facing an issue where the websocket connection stops

responding after being idle for some time. As a workaround, we

implemented a ping mechanism where we ping the server every X mins.

Keeping WebSocket connections “alive”, especially on mobile networks,
can be a challenge. There are many aspects … ping/pong every couple

of minutes might not be enough.

But now with this frequent connects and disconnect , the sockets are

piling up on the server.

Question -

  1. Do we as a client close the connection ? The autobahn java client lib

does not give any method other than disconnect(). Is it ok to use this ?

Yes. Calling disconnect() will perform a proper WebSocket closing handshake.

  1. Who should initiate the close control frame ? The client or the server ?

As you like. With WebSocket, both peers are allowed to initiate a
closing handshake.

Thanks,

Kanwar

0 Likes

#4

Hi,

I general, I would have expected that AutobahnAndroid is not yet totally robust in particular on mobile networks. We need to nail those
issues down. Robustness on mobile networks is non-trivial.

I would suggest doing that (finding corner cases, increasing robustness)
_after_ the following is finished:

We have merged code contributed by zerodivisi0n for doing automatic reconnects. This is merged, but see next:

We have started a branch "tlsnio" which implements the missing secure
WebSocket stuff. There is still work to do here .. if you wanna help
that would be great. pinetechlabs is helping here also.

The TLS stuff is significant code change. Which is the reason I'd do
reviewing the auto-reconnect and do "robustness" work thereafter.
To be able to test both WS and WSS.

Cheers,
Tobias

···

Am 18.07.2012 23:20, schrieb sangha:

Hi - Over the mobile data network , there is flakiness and when i call
close(), the following is the issue -

In WebSocketReader, run() is waiting on a blocking socket call -

public void run() {

       if (DEBUG) Log.d(TAG, "running");

       MMLogger.logInfo(MMLogger.LOG_TAG, "Inside WebSocketReader()");
       try {

          mFrameBuffer.clear();
          do {

              //MMLogger.logInfo(MMLogger.LOG_TAG, "Inside
WebSocketReader While loop()....mStopped is == " + mStopped);
             // blocking read on socket
             int len = mSocket.read(mFrameBuffer);

and in WebSocketConnection when we fail the connection, it tires to call
quit() method in WebSocketReader(), which sets the mStopped to true but
the read call is blocked since the socket over mobile data n/w has gone
to a
inconsistent state. The Join() never returns from the call in
failConnection() and we see multiple instances of reader and writer
threads running + onClose() never gets called.

if (mReader != null) {
               mReader.quit();
               try {
                  mReader.join();
               } catch (InterruptedException e) {
                  if (DEBUG) e.printStackTrace();
               }
               //mReader = null;
            } else {
               if (DEBUG) Log.d(TAG, "mReader already NULL");
            }

To workaround the issue - I have closed the input stream in quit() .
This seems to be working fine...

  public void quit() {

       mStopped = true;

       MMLogger.logInfo(MMLogger.LOG_TAG, "Inside WebSocketReader
quit(). mStopped is set to == " + mStopped);

       // this was causing the thread to hang since there is a blocking
call in run which never comes out if there is ungraceful close()
       // as a workaround - we close the input stream to wake that
thread up so that can be closed properly
       try {
         mSocket.socket().shutdownInput();
     } catch (IOException e) {
         // TODO Auto-generated catch block
         e.printStackTrace();
     }

       if (DEBUG) Log.d(TAG, "quit");
    }

Is this OK ??

On Sunday, July 8, 2012 10:04:46 AM UTC-5, Tobias Oberstein wrote:

    Hi, sorry for delay .. was totally overloaded recently.

    Am 30.06.2012 19:38, schrieb sangha:
     > Hi - We are facing an issue where the websocket connection stops
     > responding after being idle for some time. As a workaround, we
     > implemented a ping mechanism where we ping the server every X mins.

    Keeping WebSocket connections "alive", especially on mobile networks,
    can be a challenge. There are many aspects .. ping/pong every couple
    of minutes might not be enough.

     >
     > But now with this frequent connects and disconnect , the sockets are
     > piling up on the server.
     >
     > Question -
     >
     > 1) Do we as a client close the connection ? The autobahn java
    client lib
     > does not give any method other than disconnect(). Is it ok to use
    this ?

    Yes. Calling disconnect() will perform a proper WebSocket closing
    handshake.

     >
     > 2) Who should initiate the close control frame ? The client or
    the server ?

    As you like. With WebSocket, both peers are allowed to initiate a
    closing handshake.

     >
     > Thanks,
     > Kanwar
     >

0 Likes

#5

Hi - We are facing an issue where the websocket connection stops responding after being idle for some time. As a workaround, we implemented a ping mechanism where we ping the server every X mins.

But now with this frequent connects and disconnect , the sockets are piling up on the server.

Question -

  1. Do we as a client close the connection ? The autobahn java client lib does not give any method other than disconnect(). Is it ok to use this ?

  2. Who should initiate the close control frame ? The client or the server ?

Thanks,

Kanwar

Kanwar,

Look at the code I had posted patrickbrown and try that software. You ought to see the websocket dead connection go away.

···

On Saturday, June 30, 2012 1:38:43 PM UTC-4, sangha wrote:

0 Likes

#6

Look at the code I had posted below “patrickbrown” and this may solve your issue.

···

On Saturday, June 30, 2012 1:38:43 PM UTC-4, sangha wrote:

Hi - We are facing an issue where the websocket connection stops responding after being idle for some time. As a workaround, we implemented a ping mechanism where we ping the server every X mins.

But now with this frequent connects and disconnect , the sockets are piling up on the server.

Question -

  1. Do we as a client close the connection ? The autobahn java client lib does not give any method other than disconnect(). Is it ok to use this ?

  2. Who should initiate the close control frame ? The client or the server ?

Thanks,
Kanwar

0 Likes