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.

Sign up for GitHub

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

Jump to bottom

Some sockets are never disassociated from the network interface #2590

Open
stevenengler opened this issue Dec 7, 2022 · 1 comment
Open

Some sockets are never disassociated from the network interface #2590

stevenengler opened this issue Dec 7, 2022 · 1 comment
Labels
Type: Bug Error or flaw producing unexpected results
Milestone
Validate and impr...

Comments

@stevenengler
Copy link
Contributor

stevenengler commented Dec 7, 2022 •
edited
Loading

When a socket's peer address is set or changes after the socket has been associated with a network interface, that socket will never be disassociated from the network interface, which will cause the socket to stay in memory and won't make the socket's port available for other sockets.

For example:

  1. socket() - the application creates a new UDP socket
  2. bind() - the application binds the socket to some address; the socket is associated with the network interface using the key: <ip>:<port>|0:0
  3. connect() - the application sets the peer address of the socket
  4. close() - the socket is closed; the socket is disassociated from the network interface using the key <ip>:<port>|<peer_ip>:<peer_port>, but this key doesn't exist so the disassociation silently fails
  5. the socket remains associated with this interface until the end of the simulation

I think this is also an issue for client TCP sockets that are manually bound (bind() called before connect()).
@stevenengler stevenengler added the Type: Bug Error or flaw producing unexpected results label Dec 7, 2022
@stevenengler stevenengler changed the title Some UDP sockets are never removed from the network interface Some UDP sockets are never disassociated from the network interface Dec 7, 2022
@stevenengler stevenengler changed the title Some UDP sockets are never disassociated from the network interface Some sockets are never disassociated from the network interface Dec 7, 2022
@stevenengler stevenengler mentioned this issue Dec 8, 2022
Merged
@stevenengler stevenengler mentioned this issue Jun 7, 2023
Merged
stevenengler added a commit that referenced this issue Jun 8, 2023
@stevenengler
Add an AssociationHandle which disassociates the socket when dropped (
5c640f9 
#3009)

The purpose of the handle is to make it harder to accidentally forget to
disassociate the socket, to have multiple associations, or to
disassociate a different socket address than what was originally
associated. For example when re-associating a socket with another
address. See for example #2590. This could be made nicer if the network
interface was in rust, but I think this is good enough for the time
being.
@stevenengler
Copy link
Contributor Author

This is fixed now for UDP sockets due to #2981, and should hopefully be prevented in the future due to #3009. We can probably close this once we use the AssociationHandle for TCP sockets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Type: Bug Error or flaw producing unexpected results
Projects
None yet
Milestone
Validate and improve TCP simulation a...
Development

No branches or pull requests
1 participant
@stevenengler