Last Comment Bug 672384 - WebSocket connection drops on moderately-large fragmented messages
: WebSocket connection drops on moderately-large fragmented messages
Status: RESOLVED FIXED
[inbound]
:
Product: Core
Classification: Components
Component: Networking: WebSockets (show other bugs)
: 7 Branch
: x86 Mac OS X
: -- major (vote)
: mozilla8
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 690703 691733 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-18 15:47 PDT by Brian McKelvey
Modified: 2012-05-30 07:20 PDT (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch 1 (5.06 KB, patch)
2011-07-19 06:49 PDT, Patrick McManus [:mcmanus]
no flags Details | Diff | Splinter Review
patch 1a (5.09 KB, patch)
2011-07-19 06:52 PDT, Patrick McManus [:mcmanus]
cbiesinger: review+
Details | Diff | Splinter Review

Description Brian McKelvey 2011-07-18 15:47:13 PDT
BACKGROUND:
Used the WebSocket-Node library in node.js to write a test server with matching client to test receiving fragmented messages of various sizes.

The JavaScript client requests increasingly larger messages from the server forever or until the user disconnects.  The purpose is to verify that messages are fragmented correctly by the server and reconstituted correctly by the client.

There is a matching node.js console client that works fine.

Tested against Aurora 7.0a2

Test server can be obtained by cloning the WebSocket-Node git repo:
https://github.com/Worlize/WebSocket-Node

Execute:
test/fragmentation-test-server.js --help
and
test/fragmentation-test-client.js --help

Once the server is running, point Aurora 7 to http://localhost:8080

EXPECTED BEHAVIOR:

Once connected, the browser should continually print out messages indicating that it received increasingly larger messages until the user disconnects or a limitation is reached (i.e. the aggregate message size is too large)

ACTUAL BEHAVIOR:

Firefox will drop the connection and emit an 'error' event from the websocket object on messages that roughly exceed 25,000 bytes.  The threshold of message size that triggers the problem is not entirely consistent, but usually seems to be roughly around 25,000 bytes.  However sometimes it will remain stable for messages up to 100,000 bytes.

Behavior can be compared against the console-mode fragmentation-test-client.js implementation.

The node.js test client and server were run against node v0.4.9
Comment 1 Brian McKelvey 2011-07-18 15:54:09 PDT
Also, when Aurora drops the connection, it does not first send a close frame with the expected error code.  It just instantly closes the underlying TCP socket.

I would expect it to send one of the following error codes to the server before closing the socket:
1002 - Protocol Error
1004 - Message Too Large
Comment 2 Patrick McManus [:mcmanus] 2011-07-19 06:39:55 PDT
Brian, You win a special award of some kind for best test case. If we had such a thing :)

The issue here is a "shift the accumulation buffer" optimization that none of the other fragment test cases have managed to hit. Thanks! It can result in fragmented parts of the message being lost, which resulted in the failure.
Comment 3 Patrick McManus [:mcmanus] 2011-07-19 06:49:25 PDT
Created attachment 546774 [details] [diff] [review]
patch 1
Comment 4 Patrick McManus [:mcmanus] 2011-07-19 06:52:05 PDT
Created attachment 546776 [details] [diff] [review]
patch 1a

forgot to put a comment in the obsoleted patch. code content is the same.
Comment 5 Brian McKelvey 2011-07-19 09:44:59 PDT
A special award?  I'm glad I could be helpful!
Comment 6 Brian McKelvey 2011-07-19 10:26:27 PDT
Oh I should mention that I strongly suspect this bug also affects the current Firefox 6 beta.  I didn't write exhaustive test code for it though because Fx6 implements draft-07 and my code has all been updated for draft-09.  But I did fire up the draft-07 branch of my code to try something against Fx6 and experienced the same problem that originally caused me to look into this issue for Fx7.
Comment 7 Marco Bonardo [::mak] 2011-07-25 06:03:16 PDT
http://hg.mozilla.org/mozilla-central/rev/df6aa347bc83
Comment 8 Patrick McManus [:mcmanus] 2011-09-30 07:00:21 PDT
*** Bug 690703 has been marked as a duplicate of this bug. ***
Comment 9 Patrick McManus [:mcmanus] 2011-10-04 06:51:44 PDT
*** Bug 691733 has been marked as a duplicate of this bug. ***
Comment 10 Florian Wiechers 2011-10-04 07:08:19 PDT
The early bird cathes the worm :)
Thanks!
I'll continue testing on FF8.

Note You need to log in before you can comment on or make changes to this bug.