Question about WebSocketConnectionPtr::send

[eniv]

Hi, I'm wondering if WebSocketConnectionPtr::send is a blocking method? This is of an interest since I'm interested in understanding how would a websocket server implemented with Drogon cope with sending large amount of data to multiple connections, some are slow and some are fast? If the send method does not block and can be queued on any i/o thread in the event loop, is there a way to tell when it completed? Thank you in advance.

[an-tao]

No, WebSocketConnectionPtr::send method doesn't block the current thread. Because of the complecation of network transporting, it hard to know when the data is sent completely to clients if there is not any application layer ack messages received. Drogon can ensure that messages are corractly sent to clients if no brocken occurs on the connection.

[eniv]

That's good to know. Looks like the underlying TcpConnectionImpl::queueInLoop method will enqueue the formatted message until it is sent out. Does this queue have a capacity limit? The reason it would be nice to have a send completion callback is to avoid a situation of overflowing or expanding this queue without a limit by avoiding additional transfers until the current one completed.

[an-tao]

We can do this by adding a new send method with a callback parameter. This callback can only indicate that the message has been emptied from the application's queue. As for whether it has been received by the client, the user needs to add a receipt message at the application layer to know that. IMHO, the messages sent on the websocket generally only serve as prompts or notifications. These messages are very short and should not cause serious problems even if no callback is added. @rbugajewski, @marty1885 what do you think about this?

[rbugajewski]

I think a hook after dequeue is nice, and won’t hurt, especially if it is just an alternative to the non-callback method, but as @an-tao already mentioned this will give us only Drogon-internal information, as it is inherent to WebSocket to ignore some state.

[eniv]

Thank you both. In my application, I am streaming data from a server connected to some hardware in chunks of ~64KB and as fast as the client can consume. Correct me if I'm wrong, but isn't one of the ideas behind a websocket is guaranteed data transfer? Wouldn't a dequeue callback guarantee that the socket isn't flooded? Otherwise, is custom flow control the only way to throttle the connection?

[rbugajewski]

Correct me if I'm wrong, but isn't one of the ideas behind a websocket is guaranteed data transfer?

I’m not sure if we are on the same line of understanding here, but WS will basically give you no guarantees whatsoever. You would need to introduce it as some custom protocol on top of it.

Wouldn't a dequeue callback guarantee that the socket isn't flooded? Otherwise, is custom flow control the only way to throttle the connection?

I don’t think this will guarantee you fully responsive clients. In my opinion the callback could only help to empirically test the limits of the clients, and then to manually throttle. It is a very ugly solution.

[eniv]

Let me try to rephrase: how do I know if a call to WebSocketConnectionPtr::send actually sent the data or not?

[rbugajewski]

Let me try to rephrase: how do I know if a call to WebSocketConnectionPtr::send actually sent the data or not?

This would be doable by adding a send method with a callback as @an-tao already mentioned.

[Mis1eader-dev]

No, WebSocketConnectionPtr::send method doesn't block the current thread. Because of the complecation of network transporting, it hard to know when the data is sent completely to clients if there is not any application layer ack messages received. Drogon can ensure that messages are corractly sent to clients if no brocken occurs on the connection.

Does send() copy? Is the following code safe?

size_t len = -1;
char* data = new char[len];
/* Populate the data */
conn->send(data, len);
delete[] data;

[marty1885]

Does send() copy? Is the following code safe?

It may or may not depending on if you are calling send() on the same thread as the client is bounded to. But in any case. We ensure that you can delete the data after calling the function. (If we need it, we'll make a copy internally).

[Mis1eader-dev]

But in any case. We ensure that you can delete the data after calling the function. (If we need it, we'll make a copy internally

Thank you for clarifying, was good until it got to the last part, how does drogon determine whether a copy is needed?