-
Notifications
You must be signed in to change notification settings - Fork 171
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
feat: make iroh-gossip message size configurable #2312
Comments
Something larger than 128kb would be good enough, this is what we want to support for WebXDC APIs. |
seems like this should be just configurable |
dignifiedquire
changed the title
Make iroh-gossip message size limit larger
feat: make iroh-gossip message size configurable
May 22, 2024
3 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 5, 2024
## Description Add configuration option for `max_message_size` for `iroh-gossip::proto::Config`. This `Config` gets used in `iroh-gossip::Gossip::from_endpoint`. `iroh-docs` still uses the default 4096 bytes. The `max_message_size` configuration is useful for folks using `iroh-gossip::Gossip` as its own library. closes #2312 ## Breaking Changes Adds: `iroh-gossip::Gossip::max_message_size` - that reports the configured maximum message size for the gossip actor. Changes: `iroh_gossip::net::util::read_message` now takes a `max_message_size: usize` parameter `iroh_gossip::net::util::write_message` now takes a `max_message_size: usize` parameter `iroh_gossip::net::util::read_lp` now takes a `max_message_size: usize` parameter Removes: `iroh-gossip::proto:: MAX_MESSAGE_SIZE` const ## Change checklist - [x] Self-review. - [x] Documentation updates if relevant. - [x] All breaking changes documented.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is a TODO here:
iroh/iroh-gossip/src/net.rs
Lines 30 to 31 in 370075c
I ran into this problem, after trying to send a large message over gossip it stops working (in Delta Chat). Maybe it is our error handling that is wrong, have not investigated further yet.
I wanted to send PCM audio, in 4096 bytes with a single channel of 32-bit floats at 8kHz I can only encode 128ms of audio (8 * 4096 / 32 / 8000) per message. Will split into chunks of 3k bytes now just to make sure, but would be nice to have less overhead and just avoid the problem of the channel silently failing because the message is too large.
The text was updated successfully, but these errors were encountered: