You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when sending a message from a node to another we use the broadcast method setting height to 0 (so the message is not forwarded to other peers).
This effectively implements a unicast transmission using a broadcast method.
This might be confusing and hinders a clear specification of the protocol.
Possible solution design or implementation
Differentiate broadcast and unicast messages, with unicast not including broadcast-specific fields, like the message 'height'.
The text was updated successfully, but these errors were encountered:
I've tried playing around with it a bit, and the implementation was quite simple.
However, the problems started when I touched the raptorq encoder/decoder.
I end up with a lot of duplicate code for the encoder part and, for the decoder part, there is also duplicated cache management.
I don't know if the loss of code maintainability is worth the 1 byte gain.
It should also be taken into account that the library already exposes distinct methods for broadcast (where the height is needed) and send (where only the destination ip is required).
Maybe it would be useful to return to this issue in case we decide to switch UDP with QUIC #121 (and in this case we would not need a FEC)
Summary
Currently, when sending a message from a node to another we use the broadcast method setting height to 0 (so the message is not forwarded to other peers).
This effectively implements a unicast transmission using a broadcast method.
This might be confusing and hinders a clear specification of the protocol.
Possible solution design or implementation
Differentiate
broadcast
andunicast
messages, withunicast
not including broadcast-specific fields, like the message 'height'.The text was updated successfully, but these errors were encountered: