Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sockjs-client and websocket continuation frames? #362

Closed
rmelick opened this issue Mar 8, 2017 · 5 comments
Closed

sockjs-client and websocket continuation frames? #362

rmelick opened this issue Mar 8, 2017 · 5 comments

Comments

@rmelick
Copy link

rmelick commented Mar 8, 2017

Hi All,

Summary: Does the sockjs-client support websocket continuation frames?

We have been doing some work in the vertx sockjs server implementation to support continuation frames at the websocket level (eclipse-vertx/vert.x#1808, vert-x3/vertx-web#520). Continuation frames are used in the websocket protocol to allow you to send a message that would be larger than the maximum frame size supported by a server or client by breaking it up into multiple pieces. Two popular java websocket implementations have the following default frame sizes:

  • netty: defaults to 65536 bytes
  • tomcat defaults to 8192 bytes.

This means if you want to send a large websocket message (say 100kb) from a server using tomcat, the server will need to split it into multiple websocket frames before passing it to the tomcat library. I believe this is very similar to http chunking.

My question is, does the sockjs-client javascript library support websocket continuation frames? Would it make sense to add additional tests to the protocol definition about support for large messages (which would probably require continuation frames)? My understanding is that this would not require the addition of chunking to the sockjs protocol as mentioned in #205, since this is specific to websockets. Basically, the implementation requires buffering the received partial (continuation) frames until the complete message is received, and then passing it to the client code.

@brycekahle
Copy link
Contributor

Isn't this something the browser should take care of when using WebSockets? We do not have control of what opcode is used when sending data from a browser.

@brycekahle
Copy link
Contributor

In Node.js mode, this is something faye-websocket-node should be handling, if they do not already.

@leolux
Copy link

leolux commented Jul 11, 2018

Why does the client side library make use of the max frame size then? See

for (i = 0; i < 65536; i++) {

@brycekahle
Copy link
Contributor

@leolux That is not the max frame size. That code is generating an array of every character from 0 to 65535.

@brycekahle
Copy link
Contributor

Closing due to inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants