-
Notifications
You must be signed in to change notification settings - Fork 241
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
Lower the size of maximum waku message to 125KiB #4955
Comments
@richard-ramos, @cammellos, can you think of any other factors that should be considered before introducing this change? |
CC: @John-44, @jrainville, @felicio |
Something to keep in mind that maximum is not applied to the This means that the logic for segmenting messages must do so in values less than 150kb, since we need to take into account these other field, as well as the extra bytes that are added due to protobuffer serialization. |
If this line is removed, Line 244 in 8086b24
|
Thanks @richard-ramos. I has been already taken into account: status-go/protocol/common/message_sender.go Lines 1339 to 1345 in 8086b24
I believe 37.5KiB (25% from 150) for metadata is more than enough 🤔 |
@osmaczko I would not introduce it for the time being, in order to avoid unknowns, unless really necessary, since we have a tight release schedule |
We just discussed the same in our stand up 😄 We agree, I set it for 2.29 so that Web has time to adapt their code to support chunks and also so that we have enough time to test it. |
@fryorcraken what do you think about this? I think this might be adding a bit too much fuel to the fire, and might make it debugging message reliablity harder, what do you think? |
For what it's worth, it would mostly affect community descriptions and image messages, since normal messages are smaller than that limit. |
I do not believe this would impact reliability so I would leave it out at this point in time. Message size capping is helpful for:
If (1) is necessary then we can review. As I am not sure what would be the effect on latency if the messages are just being split in smaller chunks (my instinct says it would help overall but would need to verify). For (2), this would be a necessary step to introducing RLN. We would want to introduce RLN when we want to scale 1:1 messages on a set of shards or if we want to have strong bandwidth guarantees for communities. Cc @jm-clius |
Agree with @fryorcraken on this, at this point better not make this change as this doesn't affect anything other than identifying bandwidth usage (that too once RLN is in place). Maybe this change can be taken up as part of next level scaling as mentioned above while RLN would be integrated. That too, if the approach for RLN integration is going to be via a serviceNode that offers free-tiers, then the messageSize may not have an impact as message would be first sent to a serviceNode which would in-turn disperse in the network. |
Problem
As of now, the maximum waku message size is 1MiB. According to waku specs, the absolute maximum size should be 150KiB and the recommended one is 4KiB.
EDIT:
Even though waku specifies the maximum to 150KiB, we shouldn't go higher than 125KiB.
status-im/status-desktop#9923
Implementation
Notes
This change will result in the segmentation of most messages. The segmentation mechanism is designed to reconstruct messages with any segment size, ensuring backward compatibility with changes such as this one. Segmentation was introduced in version 2.27.0. Versions prior to this will not be able to process segmented messages.
Blockers
The text was updated successfully, but these errors were encountered: