The current implementation leads to exceptions when it is used to encode zero-length streams. To ensure that, I'd suggest the following enhancements:
The encoder adds a Buffer('0x00', 'hex') in case msgSize is 0.
The decoder reads the first bit and determines whether the msgSize is 0 and tries to read the message only if msgSize > 0
Compute data.length only once and prevent Buffer.concat from computing the length again.
Purpose of the enhancements:
When using the library in combination with libp2p, it happens once in a while that some nodes answer with empty messages that leads to an exception at the receiver when using length-prefixed pull-streams. In general, empty messages doesn't make any sense. But when using it in a p2p context, they're useful to tell other nodes that they cannot help with that issue and have therefore no answer.
dignifiedquire
commented
5 years ago
The current implementation leads to exceptions when it is used to encode zero-length streams. To ensure that, I'd suggest the following enhancements:
Buffer('0x00', 'hex')in casemsgSizeis0.msgSizeis0and tries to read the message only ifmsgSize > 0data.lengthonly once and preventBuffer.concatfrom computing the length again.Purpose of the enhancements: When using the library in combination with libp2p, it happens once in a while that some nodes answer with empty messages that leads to an exception at the receiver when using length-prefixed pull-streams. In general, empty messages doesn't make any sense. But when using it in a p2p context, they're useful to tell other nodes that they cannot help with that issue and have therefore no answer.
Thanks in advance ;-) Robert