Closed gabrielmer closed 9 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
9bc5ec1
) 83.13% compared to head (73cac43
) 83.18%. Report is 1 commits behind head on unstable.
Could you please elaborate on "reused across the codebase"?
Could you please elaborate on "reused across the codebase"?
Yes, in my specific case I want to check before sending a message if it's greater than the allowed limit. The idea is to avoid hardcoding 1024*1024 and referring to a global const, so if that value changes we don't introduce a bug.
This seems to be a parameter and 1024*1024
is the default value. Can you pass the value you want to use instead (that could be 1024*1024 too)?
@Ivansete-status thank you for elaborating on it, but I still don't understand why Waku needs to use Gossipsub default max message size in its codebase. Are you happy using whatever value it happens to have? Wouldn't it be better if Waku chose a value (which could be the same as the default) aligned with its needs and use it as the parameter value when creating the Gossipsub instance?
But I don't have a strong opinion on that, feel free to merge it.
Actually, we also have a maxMessageSize
in pubsubpeer.nim
file for the PubSubPeer
type. I don't know the reason for the duplication, it might be important to analyze it before merging this PR.
er, given this is a default for a runtime value, it doesn't make much sense checking against the constant - nwaku should be checking against the runtime value at the time of instantiation - if nwaku wants to use a constant, it should use its own constant both when instantiating libp2p and nwaku.
more broadly, the thing nwaku needs to be wary of is if different nwaku nodes have different max message size values - for example when upgrading from one version to another - such a change generally must see a coordinated release / update
er, given this is a default for a runtime value, it doesn't make much sense checking against the constant - nwaku should be checking against the runtime value at the time of instantiation - if nwaku wants to use a constant, it should use its own constant both when instantiating libp2p and nwaku.
Makes sense! Not sure why in nwaku we use the default value of nim-libp2p and not a value set by us in the first place. Is it by the assumption that the default value should be a reasonable and well-tested one? @Ivansete-status @jm-clius
Not sure why in nwaku we use the default value of nim-libp2p
We don't afaict. Where default values in nim-libp2p is considered reasonable we don't necessarily make this configurable or an explicit constant in Waku, but in the case of max message size it is (and should be) a Waku constant:
Constant here - https://github.com/waku-org/nwaku/blob/master/waku/waku_core/message/default_values.nim#L8 Used to initialise libp2p pubsub here - https://github.com/waku-org/nwaku/blob/e4e147bcbb71366b159d0f2dcfddfe85fa85b1af/waku/waku_relay/protocol.nim#L168
We don't afaict. Where default values in nim-libp2p is considered reasonable we don't necessarily make this configurable or an explicit constant in Waku, but in the case of max message size it is (and should be) a Waku constant:
Constant here - https://github.com/waku-org/nwaku/blob/master/waku/waku_core/message/default_values.nim#L8 Used to initialise libp2p pubsub here - https://github.com/waku-org/nwaku/blob/e4e147bcbb71366b159d0f2dcfddfe85fa85b1af/waku/waku_relay/protocol.nim#L168
Ooh that's great! So it was a big misunderstanding then. For some reason we thought we used 2 different max values, libp2p's and Waku's. Closing this PR.
Thanks so much and apologies :))
Moving the maximum message size value as a global constant so the value can be accessed and reused across the codebase