Hi,
We are using the libp2p PubSub (FloodSub) functionality and we need to send messages in different sizes. According to this, the maximal message size is 1MB, although I am not sure that the JS implementation we use enforces this currently.
My question is what can be done in case we need to use larger message sizes?
Thanks!
JS is not currently enforcing this at the pubsub level like go is doing, however, mplex does limit to a message size of 1MB https://github.com/libp2p/specs/tree/master/mplex#writing-to-a-stream. For JS, this would need to be resolved in order to send messages larger than 1MB.
We could look at configuring this, but if those nodes are connected to the rest of the network and they are restricted to 1MB, messages will get dropped. If the messages can’t be split up, the most reasonable approach might be to look at extending the pubsub and muxer protocols to support these needs to avoid unexpected message dropping.
Thanks for the quick reply.
We do consider applying some mechanism for message splitting and reassembly, but before going that path we wanted to understand the current limitations.
Could you please elaborate more on the mplex limitation?
We were able to send more than 1MB in JS (between 2 nodes running on the same machine), but got dropped messages when trying to send ~3MB so we guessed that the current JS implementation does not strictly enforce it.
Thanks!
Something to keep in mind, if you need to send larger datasets pubsub is not going to be an efficient way of doing that as peers are likely to receive a message multiple times. Using other mechanisms of fetching the data rather than broadcasting would be more efficient, https://github.com/libp2p/specs/issues/118#issuecomment-499688869.
You’re correct, js-libp2p-mplex is not currently doing any enforcing of this at the moment. There is a newer version of mplex, pull-mplex that does enforce the limit and which we will be migrating js-libp2p-mplex to use this. The code is more efficient and has better performance of high throughput streams.
It’s not currently splitting larger messages into multiple chunks but it really should be. If you really need to send large messages over pubsub, this built in chunking behavior will probably be necessary to prevent messages from dropping.
Makes total sense, thanks!