Do we care about address length vs message length in circuit-relay?

[dryajov]

Now that we have a proper protobuf spec for the circuit-relay messages, do we care about individual addresses length? It seems like we should restrict the overall size of the protobuf message, but other than that, checking for address length doesn't seem to add any value anymore. @vyzo proposed 4096 as an arbitrary message size, which I think is reasonable.

Given this, lets remove the address length restriction in favor of a message size.

@diasdavid @whyrusleeping @lgierth

[dryajov]

This should also eliminate the need for the ADDRESS_TO_LONG error codes, but possibly introduces a new one - MSG_TOO_LARGE

edit: typo

[vyzo]

Fwiw the Go implementation I am working on does not emit any ADDRESS_TOO_LONG messages, because they are not relevant anywhere.

For the max message size, it's not explicitly tested either.
A delimited reader is created, and if that fails to parse the message it currently closes the connection, although it would certainly be nicer to emit an error message.
Perhaps we want a MALFORMED_MSG error instead of MSG_TOO_LARGE?

[jvican]

I think a MALFORMED_MSG is a better candidate, especifically if it can capture the reason why it fails: either because the message is too large, there is an encoding issue, etcetera.

[dryajov]

@jvican we're not currently sending error messages back, just codes - hence the current 200 vs 300 error code ranges, they signal which leg of the relay broke.

[whyrusleeping]

I think MSG_TOO_LARGE is a good message, though its a fair argument that MALFORMED_MSG is equivalent, given that the most common cause of a "too long" message is that its data is all screwed up. That said, messages could be malformed for other reasons, but have a valid length. I'm fine with either choice.

[mxinden]

This is addressed in the current circuit relay v2 design (libp2p/go-libp2p-circuit#125). Unless anyone objects this can be closed once circuit relay v2 lands in the spec repo.