Use persistent XPC connection for IP allocation management.#1395
Open
jglogan wants to merge 2 commits intoapple:mainfrom
Open
Use persistent XPC connection for IP allocation management.#1395jglogan wants to merge 2 commits intoapple:mainfrom
jglogan wants to merge 2 commits intoapple:mainfrom
Conversation
- Closes apple#1378. - At present, IP allocation involves four parties: the ContainersService and NetworksService in the API server, the SandboxService running in `container-runtime-linux`, and the NetworkService running in `container-network-vmnet`. - Each NetworkService `allocate()` requires a corresponding `deallocate()` or an IP address gets leaked. - This change gets rid of `deallocate()` and instead changes `allocate()` so that the caller received an XPC connection. The caller holds this connection for as long as the network attachment is alive (essentially as long as the container is running). When the connection disconnects, the NetworkService automatically unregisters the hostname:IP association. - Removed IP allocation from the API server, restoring the old process by which sandboxes directly allocate from networks. To deal with the eventual possibility of more network plugins than `container-network-vmnet`, the bootstrap call requires an additional parameter `networkPluginInfos` that is the same size as the attachments array in the container configuration, and identifies the plugin for each attachment.
3 tasks
vxnkjyffmq-code
approved these changes
Apr 6, 2026
dcantah
reviewed
Apr 6, 2026
| request.set(key: NetworkKeys.macAddress.rawValue, value: macAddress.description) | ||
| } | ||
|
|
||
| let client = createClient() |
Member
There was a problem hiding this comment.
If we changed this client to the model that some of our others have taken (maintain a long lived xpc connection instead of creating a new one for every request), does this screw things up with this persistent routes idea?
Comment on lines
+52
to
+54
| /// Persistent XPC connections to each network plugin, one per network attachment. | ||
| /// Held for the container lifetime; deallocation happens automatically when these are released. | ||
| private var networkConnections: [XPCClient] = [] |
Contributor
There was a problem hiding this comment.
Maybe this is a naive question, but could this ever cause an issue if we have a lot of running containers with a lot of networks in use?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
container-runtime-linux, and the NetworkService running incontainer-network-vmnet.allocate()requires a correspondingdeallocate()or an IP address gets leaked.deallocate()and instead changesallocate()so that the caller received an XPC connection. The caller holds this connection for as long as the network attachment is alive (essentially as long as the container is running). When the connection disconnects, the NetworkService automatically unregisters the hostname:IP association.container-network-vmnet, the bootstrap call requires an additional parameternetworkPluginInfosthat is the same size as the attachments array in the container configuration, and identifies the plugin for each attachment.Type of Change
Motivation and Context
deallocate()call was always a leak hazard.Testing