Project

General

Profile

Tigase websocket connection issues

Matthew M
Added almost 5 years ago

We star to use websocket connecting to tigase (5.2.0 beta2)

There are a couple of problems we found and your help or suggestions would be highly appreciated!

  1. We constantly observe the disconnection of websocket on the client side. We are still looking into the root cause. Do you know what kind of server log we should look into to find out it's a client or server problem? We are using webscoket strophe lib: https://github.com/strophe/strophejs.

  2. We found have to increase the buffer size during handshake, line 164 of WebsocketXMPPIOService.java

        if (buf == null) {
            buf = new byte[2048]; //increase from 1024 to 2048
        }

We increase it from 1024 to 2048, as the handshake may fail sometime due to insufficient buffer size.

Do you know what should be a good number for it?

  1. We are seeing a lot of buffer under flow exception around line 128 in WebsocketXMPPIOService.java. Do you know what will cause this?
            // here we got buffer overflow
            ByteBuffer decoded = null;
            while (cb.hasRemaining() && (decoded = decodeFrame(cb)) != null) {
                //decoded = decodeFrame(cb);
                if (decoded != null && decoded.hasRemaining()) {
                    tmp.put(decoded);
                }
            }

Exceptions:

2014-03-27 14:44:43.838 [ResultsListener-socketWriteThread-6] SocketThread$ResultsListener.run() WARNING: Protocol execution exception.

java.util.concurrent.ExecutionException: java.nio.BufferUnderflowException

at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252)

at java.util.concurrent.FutureTask.get(FutureTask.java:111)

at tigase.net.SocketThread$ResultsListener.run(SocketThread.java:586)

Caused by: java.nio.BufferUnderflowException

at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:145)

at java.nio.ByteBuffer.get(ByteBuffer.java:692)

at tigase.server.websocket.WebSocketXMPPIOService.decodeFrame(WebSocketXMPPIOService.java:394)

at tigase.server.websocket.WebSocketXMPPIOService.readData(WebSocketXMPPIOService.java:130)

at tigase.xmpp.XMPPIOService.processSocketData(XMPPIOService.java:717)

at tigase.net.IOService.call(IOService.java:257)

at tigase.net.IOService.call(IOService.java:98)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)

at java.util.concurrent.FutureTask.run(FutureTask.java:166)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)

at java.util.concurrent.FutureTask.run(FutureTask.java:166)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:679)

Replies (12)

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 5 years ago

  1. This buffer size of 1024 was estimated according to RFC 6455 using possible length of fields possible request and then rounded up. I suppose that if you web app is using cookies or if you browser adds additional header then it may be possible that this buffer size was too small for your case. I suppose that we could reimplement this handshake to be able to use small size of buffer and read additional data when needed.

As for 1 and 3, is it possible that they are related to each other? I suppose that in 3 not whole WebSocket frame header is available in buffer when we started to process it, we will need to add additional checking if we have whole frame header before processing it.

Added by Matthew M almost 5 years ago

Thanks a lot for your reply!

   I suppose that we could reimplement this handshake to be able to 
   use small size of buffer and read additional data when needed.
   we will need to add additional checking if we have whole frame header before processing it.

Do you think Tigase will release a patch on it soon? Or in the mean time, should we increase the buffer size as a temporarily solution? If so, could you point use to the code that we could increase the buffer size for problem 1, 2, and 3?

Many thanks!!

Added by Matthew M almost 5 years ago

By the way, I wonder if there is any latest XEP for Web socket?

I only found there is a draft one:

https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/

Many thanks!

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 5 years ago

There was no official specification or XEP for XMPP over WebSocket connections - only drafts. Our implementation is currently close to following draft http://tools.ietf.org/id/draft-moffitt-xmpp-over-websocket-04.txt but we are going to implement the one you mentioned as well.

Added by Andrzej Wójcik IoT 1 CloudTigaseTeam over 4 years ago

I've just rewritten part of handling WebSocket handshake as well as decoding of WebSocket frames. In new version I removed static size of buffer during handshake (new byte[1024]) and improved handling of partial frame in buffer during decoding of frame. So points 2 and 3 should be solved in new SNAPSHOT build which will be released.

Added by Subir Jolly over 4 years ago

When is the next SNAPSHOT build scheduled to be released?

Added by Wojciech Kapcia TigaseTeam over 4 years ago

New snapshots are created daily and are available either from maven repository or as a nighly builds

Added by Subir Jolly over 4 years ago

Thank you. I see 5.3.0. But I was also wondering when it will be available as a stable release to public?

Added by Wojciech Kapcia TigaseTeam over 4 years ago

As per Roadmap final version is due to in about 4 months.

Added by Subir Jolly over 4 years ago

Thank you for your response.

Added by Subir Jolly about 4 years ago

Guys, any update on this issue?

Added by Wojciech Kapcia TigaseTeam about 4 years ago

Release was pushed - final version is expected to be release by the end of January.

    (1-12/12)