WSLC networking behaviour and how Purview.Containers models it.
Mode (ContainerNetworkingMode) |
Effect | Port mappings |
|---|---|---|
null (default) |
Docker NetworkMode: "none" — no network, no IP |
❌ CreateContainer throws 0x80070057 |
None |
same as null | ❌ |
Bridged |
container gets 172.17.0.x on the session bridge; host→container mapped ports work |
✅ |
- Host bind address is IPv4 loopback only (
HostIp: 127.0.0.1). IPv6::1does not connect to the mapped port. - Clients must use
127.0.0.1, notlocalhost.localhostresolves to::1first on .NET; most clients (Npgsql, StackExchange.Redis) fall back to IPv4, but Microsoft.Data.SqlClient hangs on::1without falling back, so the SQL Server module's connection strings use127.0.0.1,{port}explicitly. - Containers in the same session can reach each other by IP (Bridged) —
wget http://<ip>:8080/works. - No name/DNS resolution between containers.
wget http://<hostname>:8080/andhttp://<container-name>:8080/fail with "bad address";/etc/hostscontains only localhost + the container's ownIP <short-id>. - There are no managed network objects (no
network create/connectinMicrosoft.WSL.Containers, unlike the CLI).
- Default
NetworkingMode = Bridgedfor containers that bind ports (or, by default, for all containers to be useful). This is baked intoContainerBuilderdefaults. GetMappedPublicPort(containerPort)readsInspect().Ports["<port>/tcp"][0].HostPort.GetNetworkIp()readsInspect().NetworkSettings.Networks.bridge.IPAddress(Bridged only).- TCP/HTTP wait strategies connect to
127.0.0.1:<hostPort>(IPv4 only). - Multi-container environments are deliberately deferred. Because there is no native DNS/alias, a future
ContainerEnvironmentBuilderwould wire containers together by passing each other's IPs (fromGetNetworkIp()) into configuration/env. The core API must not preclude this (it doesn't —GetNetworkIp+ environment are enough).
- Do not invent Docker-style
Networkobjects; the underlying semantics are just "bridged with IPs". - Do not claim container-name resolution works; it does not.