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

UDP socket abstraction needs a deregister step #427

Open
thirtytwobits opened this issue Feb 1, 2025 · 1 comment
Open

UDP socket abstraction needs a deregister step #427

thirtytwobits opened this issue Feb 1, 2025 · 1 comment
Assignees
Labels
class-requirement Issue that can be traced back to a design requiement domain-production Pertains to the shippable code rather than any scaffolding

Comments

@thirtytwobits
Copy link
Contributor

We currently simply delete socket objects when we no longer need them. For UDP multicast we need time to unregister using IGMP. Trying to run this in a destructor is an anti-pattern. We need to define a lifecycle for these abstract sockets where we remove them from use but continue to service them until the say they are ready for deletion. This would give us time to try to deregister/leave the multicast group and possibly retry if the system were out of tx buffers. Furthermore, a well-optimized system would run this IGMP de-registration step at a lower priority only sending the IGMP when there wasn't a lot of outgoing traffic in the queues.

@thirtytwobits
Copy link
Contributor Author

One option is to not handle this abstractly. Instead of deleting sockets we could simply hand them back to the media layer and let it dispose of them.

@pavel-kirienko pavel-kirienko added class-requirement Issue that can be traced back to a design requiement domain-production Pertains to the shippable code rather than any scaffolding labels Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
class-requirement Issue that can be traced back to a design requiement domain-production Pertains to the shippable code rather than any scaffolding
Projects
None yet
Development

No branches or pull requests

3 participants