Closed Bug 690703 Opened 13 years ago Closed 13 years ago

WebSocket communication over about 67577 bytes closes MozWebSocket

Categories

(Core :: Networking: WebSockets, defect)

7 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 672384

People

(Reporter: mozilla, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20100101 Firefox/7.0
Build ID: 20110927152709

Steps to reproduce:

Using firefox 6.2 and 7.0 on linux, 7.0.1 on Windows 7.
Cometd 2.4.0beta2 (latest beta with best websocket support)
Jetty 7.5.1 (latest stable 7.x line with best websocket support)

Ran a cometd program that asked for 67520 bytes of data, wrapped by some protocol guff, to give:
[{"data":{"data":"<67520 bytes here>"},"channel":"/generateddata/receive"}]

This data is received by firefox, and should be passed to the cometd.js library code, which would route it to subscribers.

I find that requesting 67519 bytes (again, wrapped by the guff above) succeeds and is delivered to my cometd subscriber successfully.  I reached this figure by trial and error, trying different values until I found the fail point.

Wireshark shows network traffic seems fine, it's not a jetty or cometd problem.  The error occurs between the data arriving at firefox, and firefox invoking cometd's websocket listener.


Actual results:

Firefox logged in the firebug Console (truncated by firebug):

Transport websocket closed MozWebSocket { url="ws://neekfenwick.dyndns...inesdemo/cometd/connect", readyState=1, bufferedAmount=0, more...}

Cometd then properly handled the failure.


Expected results:

Any size message up to the network.websocket.max-message-size = 16000000 limit seen in about:config ought to work.
I have raised this issue in the cometd google group for awareness: http://groups.google.com/group/cometd-users/browse_thread/thread/129d13dc4d49c654#

There is also sample javascript client and java server code there, though it takes some work to build your own working example.  I can provide a running server on request that you can hit the client html and see the error.

Tested with the nightly build from http://nightly.mozilla.org/ with the same cometd/jetty config and it works fine, receves the large amounts of data just fine, and cometd and jetty perform as expected.  I can request up to 15900000 bytes without error, didn't bother testing higher, 16000000 and slightly less causes error as expected due to max-message-size.
Component: General → Networking: WebSockets
Product: Firefox → Core
QA Contact: general → networking.websockets
If this works for you in FF8 (now beta), then its almost certainly a dup of 672384.

In the meantime, the workaround would be to not send fragments if jetty provides that option.
Thanks.  The jetty/cometd guys have told me to use the undocumented ws.bufferSize init-param to the cometd servlet, which allows me to set its size larger than my data, and does fix the immediate problem.  This appears to avoid the fragmentation referred to here.

<servlet>
    <servlet-name>cometd</servlet-name>
    <servlet-class>org.cometd.server.CometdServlet</servlet-class>
[cut]
    <init-param>
      <param-name>ws.bufferSize</param-name>
      <param-value>200000</param-value>
    </init-param>

The websocket comms between cometd server and cometd javascript client in Firefox can then receive my large data payload.  I don't know where the websocket comms is visible, I can't seem to find it in firebug (where HTTP traffic would have been in the Net pane XHR section, Websocket traffic simply doesn't seem to show up, even in All).

So I guess this is a dup of 672384, if you say so :)
(In reply to Nick Fenwick from comment #3)
> Thanks.  The jetty/cometd guys have told me to use the undocumented
> ws.bufferSize init-param to the cometd servlet, which allows me to set its

that's an awesome work around - thanks for sharing.

The good news is that this is fixed in FF8, and that browsers in our rapid release series (> FF 4) get upgraded very quickly when a new release comes out. So this bug isn't something that you'll have to live with on the net for very long.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: