Skip to content
This repository has been archived by the owner on Jul 23, 2019. It is now read-only.

Error polling incoming connection: frame size too big #109

Closed
swap357 opened this issue Jun 28, 2018 · 4 comments
Closed

Error polling incoming connection: frame size too big #109

swap357 opened this issue Jun 28, 2018 · 4 comments

Comments

@swap357
Copy link

swap357 commented Jun 28, 2018

While running
script/xray --listen=8080 --headless /home/user/xray/
for xray_browser

Cannot get past this-

Error polling incoming connection: frame size too big

[No UI elements on the client browser]

@swap357 swap357 changed the title proc_macro2 does not compile Error polling incoming connection: frame size too big Jun 29, 2018
@lucat1
Copy link

lucat1 commented Jun 29, 2018

Duplicate #75

@nathansobo
Copy link

Sorry about this one. We’ve shifted our focus a bit lately and left it broken, but it should be straightforward to fix.

@swap357
Copy link
Author

swap357 commented Jun 29, 2018

Sorry, I'm new to rust and custom codec development. Would you mind sharing a little more elaborate solution to the problem?

The following link no longer works-
https://docs.rs/tokio-io/0.1/tokio_io/codec/length_delimited/struct.Builder.html

@nathansobo
Copy link

nathansobo commented Jun 29, 2018

When we pass the --listen flag to the server, it sets up a TCP listener on the desired port. Whenever there is a new connection, we handle it in this closure. Inside that closure, we wrap the raw socket in a Tokio codec. The codec's job is to decode incoming bytes into proper Rust types and also to encode outgoing messages as bytes. We're using the length_delimited codec, but that isn't working for large files. So instead we need to write our own implementation of the Encoder and Decoder traits (documented here), or find some existing implementation that splits large messages into smaller pieces and buffers them. We have one example of a custom codec here, which we wrap around the domain socket connection to the Electron application when we're not running in headless mode. That one deals with JSON and line-delimited values. This one would need to split and reassemble messages, but otherwise it would be used similarly. Hope that's somewhat helpful.

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

No branches or pull requests

3 participants