Oversized messages dropped without warning

[dirkmc]

In two places in the code we drop messages that are too large.

We should probably send an error response to the sender.

It may be worth creating a transformer similar to it-length-prefixed to check message length.

[dirkmc]

@alanshaw following up on the question in the weekly sync - is it possible for an oversized message to reach js-libp2p-kad-dht? Or is this already taken care of by lower layers?

[jacobheun]

It's not, and the sizes don't match. Mplex restricts messages to 1MB, so it won't make it to the DHT. Additionally, it-length-prefixed has a default decode restriction of 4MB, so messages wouldn't make it even if the muxer allowed it.

The DHT comment of 4MB is wrong, the constant of 2 << 22 is 8MB, not 4, but it will never get called anyway. We should be able to safely remove the check in the DHT as it's superfluous.

[vasco-santos]

It seems so! Thanks for your analysis.
@dirkmc would you like to PR it?

[alanshaw]

In it-mplex an oversize incoming message will cause an error to be thrown (and caught) in the sink, which in turn will abort all the mplexed streams (sends a RESET message to the remote). The error will be re-thrown on the source side for the application to catch.

An oversive outgoing message will also cause an error to be thrown in the source, which in turn will abort all the mplexed streams (sends a RESET message to the remote).

I do not know if go-mplex deals with this - I don't remember seeing code that did...

[jacobheun]

I do not know if go-mplex deals with this - I don't remember seeing code that did...

IIRC go-mplex will actually automatically split the messages into a maximum size, which we should eventually be doing for js-mplex. So it's not possible in go, when using mplex, to send an oversized message as it is automatically sliced for you.

[alanshaw]

Ok so, I was curious - go-mplex does throw at the top level https://github.com/libp2p/go-mplex/blob/8e818a96b0e2bbdc7bd825d3c8a2e131515e78ed/multiplex.go#L568 but the splitting is done by the multiplexed streams on write:

https://github.com/libp2p/go-mplex/blob/8e818a96b0e2bbdc7bd825d3c8a2e131515e78ed/stream.go#L142-L159

[alanshaw]

libp2p/js-libp2p-mplex#100