Unable to send messages immediately about websocketpp HOT 5 CLOSED

Is process with updates performed on another thread or async task? If not it will run synchronously, producing and queuing all the update messages before ever returning control back to the library to write.

connection-write_frame definitely shouldn’t be called here.

not directly related to this issue, but I’d recommend just setting tcp no delay once, either in the open handler or socket unit handler, it applies for the duration of the connection.

if you use a thread or async task to run your processing function I’d also recommend capturing the connection hdl rather than the full connection pointer and using endpoint::send (this helps ensure proper behavior when multiple threads are in use)

from websocketpp.

It is difficult for me to multithread the task without significant cross thread access violations. Is there an async send?

from websocketpp.

Send is async, which basically is the problem. There isn't a sync send, because Asio and Websocket++ generally are designed to be used in an async environment.

To use this pattern (single thread cooperative multitasking) without threads you would do something like...

message handler

• store the details of the request somewhere
• start an async task (using the interrupt handler or timer handler) that will read request details and completion state and perform one chunk of work, send a status update, and then queue the next chunk of work
• yield (allow the message handler to return)

this returns control to the Asio event loop and allows it to process incoming and outgoing messages asyncronously and periodically call your async task (again, via the interrupt or timer handlers) to progress that task. When the task is complete the final invocation simply declines to re-queue a timer/interrupt and the task ends.

from websocketpp.

(followup)
The telemetry_server bundled example shows a pattern similar to this that uses timers. Your message handler would queue request details and yield. The timer handler would process some work, send a status update and yield. If there were no outstanding requests the timer would yield immediately. The pattern with the interrupt handler is similar, except instead of setting up a persistent timer you request an immediate interrupt via connection::interrupt(), which will call that connection back shortly at its interrupt handler. You can set the interrupt handler for a specific connection in the message handler. Do keep in mind though that unless your handler (be it the message handler, timer handler, or interrupt handler) yields control back to the single threaded event loop no WebSocket data will be processed (new data in or out) so it is best to keep the work processing tasks short and yielding somewhat frequently.

Finally: keep in mind that you don't need to multi-thread the processing task itself. It is fine for the task to run in a single thread as long as the Asio event loop processing all the network traffic is in a different thread.

from websocketpp.

Okay. Actually, converting captures for lambdas from reference to non reference took care of most of it. It wasn't that much after that. Problem solved for now.

from websocketpp.