Websocket transport disconnects if PONG arrives late even if other (data frames) are arriving

[DZabavchik]

When client is on slow connection and large payload is scheduled PONG responses end up at the end of the send queue. Server socket schedules PONG timeout and closes the connection if PONG does not arrive on time.

I guess proper fix is for all client libraries to use priority queue or schedule PONG responses ahead of any pending data frames.

[oberstet]

When client is on slow connection and large payload is scheduled PONG responses end up at the end of the send queue.

yeah, I can see the problem

I guess proper fix is for all client libraries to use priority queue or schedule PONG responses ahead of any pending data frames.

rgd the latter, probably needs more:

• configure auto-fragment size (we have that in autobahn-python and crossbar)
• since autobahn-python is single-thread async, and when using twisted: consumer-producer pattern

for the latter, here is an example https://github.com/crossbario/autobahn-python/tree/master/examples/twisted/websocket/streaming

---

having said that, I just saw your PR (https://github.com/crossbario/autobahn-python/pull/1328): I like that a lot!

it is yet another way (different from above routes) - which isn't strictly RFC6455 compliant to the letter (I think .. without re-reading the spec), but I wouldn't care, because it seems like a pragmatic and simple solution and does not harm (rgd what the spec really cares about)

@meejah thoughts?

[DZabavchik]

Thank you. That was the intent. Since that PONG is not used for anything except for: a. Keep-alives and preventing load-balancers from dropping silent connections b. Detecting lost route to client (no FIN ACK)

And traffic arriving from client ensures both + we are actually sending PING, just don't care if PONG arrives on time and with same content.

[meejah]

Yeah, I like the idea: after all, the intent is to know "is this connection alive" and if we're getting data, it is...