Congestion control about nv-websocket-client HOT 9 CLOSED

Currently, I have no plan to add congenstion control.

How do you expect congention control to work? For example, should sendXxx methods block when the number of queued frames is too large?

from nv-websocket-client.

It's a one of possible option (probably best one). Another possible option is to throw exception. In any case it will be great to have ability to control congestion somehow because right now it's just crash application by OOM.

I found a way how I could implement congestion control for writing thread on top of your library by putting frame to LinkedBlockingQueue before send to websocket and listening onFrameSent to control send flow.

If you don't want to implement congestion control out-of-box I assume that you could close this ticket.

from nv-websocket-client.

I've tried to implement suggested approach but code looks like a mess.

It will be great to have something useful for congestion from library. It could be

• BlockingQueue mFrames in WritingThread with ability to specify the length of queue somewhere (factory?). sendFrames could use this queue as is without creating new ArrayList buffer for current frames. Moreover, I suggest that this simplify waiting logic in WritingThread.
• Method to send frames synchronously.
• New callback before or after sendFrame(frame) is called. In this case users could control the flow in this callback. Right now I need to listen all onFrameSent onFrameUnsent and onSendError to understand when frame is passed to Socket.

from nv-websocket-client.

Released version 1.15. Please try WebSocket.setFrameQueueSize(int) method. The following is an excerpt from README.md.

Congestion Control

sendXxx methods queue a WebSocketFrame instance to the internal queue. By default, no upper limit is imposed on the queue size, so sendXxx methods do not block. However, this behavior may cause a problem if your WebSocket client application sends too many WebSocket frames in a short
time for the WebSocket server to process. In such a case, you may want sendXxx methods to block when many frames are queued.

You can set an upper limit on the internal queue by calling setFrameQueueSize(int) method. As a result, if the number of frames in the queue has reached the upper limit when a sendXxx method is called, the method blocks until the queue gets spaces. The code snippet below is an example to set 5 as the upper limit of the internal frame queue.

// Set 5 as the frame queue size.
ws.setFrameQueueSize(5);

Note that under some conditions, even if the queue is full, sendXxx methods do not block. For example, in the case where the thread to send frames (WritingThread) is going to stop or has already stopped. In addition, method calls to send a control frame (e.g. sendClose() and sendPing()) do not block.

In addition, a new callback method, onSendingFrame(WebSocket, WebSocketFrame) has been added to WebSocketListener. It is called right before a frame is sent to the server.

from nv-websocket-client.

Cool! My two cents:

1. Your implementation cause deadlock and leak of resources when writing thread is waiting for space in mFrames and disconnect happens. It happens because of mStateManager locking isn't not released when you wait on writing thread.

ReadingThread <--- Frozen for at least 3m 49 sec
com.neovisionaries.ws.client.WebSocket.sendFrame(WebSocketFrame) WebSocket.java:1904
com.neovisionaries.ws.client.ReadingThread.readFrame() ReadingThread.java:342
com.neovisionaries.ws.client.ReadingThread.main() ReadingThread.java:93
com.neovisionaries.ws.client.ReadingThread.run() ReadingThread.java:61



WritingThread <--- Frozen for at least 3m 49 sec
com.neovisionaries.ws.client.WebSocket.disconnect(int, String) WebSocket.java:1785
com.neovisionaries.ws.client.WebSocket.disconnect() WebSocket.java:1699
...

2. The WritingThread frees all elements in once. For example if I set queue length = 100 and queueFrame is locked then I will wait until all previous 100 frames will be sent and new frames will add to intermediate LinkedList which cleans mFrames. It will give me 100 elements quota. I'm expecting then when I sent one frame then I could be able to add one more frame to queue.
   https://github.com/TakahikoKawasaki/nv-websocket-client/blob/master/src/main/java/com/neovisionaries/ws/client/WritingThread.java#L308

3. New callback is awesome. In spite of the issue with deadlock I could provide my own congestion control algorithm and get working application. It's pretty sweet.

from nv-websocket-client.

Thank you for your feedback. I'll look into the deadlock issue and try to find a solution.

from nv-websocket-client.

@avasenin
I changed the code for 1) and 2). Could you test nv-websocket-client-1.16-SNAPSHOT?
If you cannot test SNAPSHOT, it would be doable to release 1.16 without your testing.

from nv-websocket-client.

@avasenin I released a new version 1.16. Please try the new version.

from nv-websocket-client.

Looks good. I will perform some tests until the end of week. I reopen this issue if I find something.

Thanks for your fast responses and time.

from nv-websocket-client.