Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement unicast messages #122

Open
fed-franz opened this issue Feb 28, 2023 · 1 comment
Open

Implement unicast messages #122

fed-franz opened this issue Feb 28, 2023 · 1 comment
Labels
type:enhancement Issues concerning code or feature improvement (performance, refactoring, etc)

Comments

@fed-franz
Copy link
Contributor

fed-franz commented Feb 28, 2023

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 and unicast messages, with unicast not including broadcast-specific fields, like the message 'height'.

@fed-franz fed-franz added the type:enhancement Issues concerning code or feature improvement (performance, refactoring, etc) label Feb 28, 2023
@herr-seppia
Copy link
Member

herr-seppia commented Mar 9, 2023

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:enhancement Issues concerning code or feature improvement (performance, refactoring, etc)
Projects
None yet
Development

No branches or pull requests

2 participants