Websocket response + disconnect race condition?

[SeanMollet]

I'm shipping video via WebRTC to a "server" with a unique websocket behavior:

Connect, send SDP, it immediately responds with an answer and then disconnects.

Most of the time, onClosed ends up getting called and onMessage never is. Wireshark shows that the answer was received. Digging into PollService::runLoop, it seems like this is caused by a race. If the close is executed before the runLoop comes back around, the message ends up dropped on the floor.

Am I reading the code correctly?

From onClose, is there any easy way to get the data? receive() gives me nothing.

Happy to dig in and solve this, but wanted to get some thoughts from others on the best approach and/or validation that I'm reading all of this correctly.

Thanks

[SeanMollet]

I'm using TLS and it seems the problem is that the socket close triggers TlsTransport::stop(), which unregisters the incoming callback., thus eating the received message.

[paullouisageneau]

Thank you for reporting, you are right, data can still be waiting for TLS decryption when TCP disconnect. Could you please try with #1266 ?

[SeanMollet]

@paullouisageneau Testing now, will report back in a few minutes

[SeanMollet]

Tested with #1266, fixed.