search

peace-maker / sm-websocket

A WebSocket protocol implementation to create a direct connection between webbrowsers and gameservers.
https://forums.alliedmods.net/showthread.php?t=182615
43 stars 10 forks source link

Support for fragmented frames #1

Open bawNg opened 10 years ago

bawNg commented 10 years ago

Please could you implement support for fragmented frames, they have become mandatory for websockets.

Modern browsers including the embedded WebKit browser in many Source engine based games are now using fragmented frames at least some of the time which is causing all services that rely on sm-websocket to be unreliable. There is no way for the client-side Javascript to force the browser not to use fragmented frames, so there is currently no workaround for this issue.

From what I have observed, most clients appear to only use fragmented frames some of the time, while a few will use them almost all of the time causing all connections attempts from that client to fail.

Thanks for the great plugin.

peace-maker commented 10 years ago

Please try if this is sufficient already d3b22f5576cad4f7f6591f67557e8155ef0001e0.

bawNg commented 10 years ago

Thanks for the really quick response.

When I tested that version in my Google Chrome browser, after a few page reloads it started disconnecting as soon as it connected and continued to do so for over 100 reconnection attempts before I stopped it. The plugin logged "Received fragmented control frame. (34)".

I then commented out the CloseConnection() call when a fragmented control frame is received and printed a warning with the opcode to the console log. The "fragmented control frame" opcodes that were ignored were mostly 13 and also 15. Everything else appeared to function fine, but my application usually doesn't send large messages so I doubt it was using any fragmented frames.

I will do some testing with large messages when I have some time and see what happens.

peace-maker commented 10 years ago

Some wireshark dump of that traffic would help :) Opcode 34 is not defined at all and 13, 15 are reserved and not specified yet. I doubt chrome would invent new opcodes so there must be some parsing error.