This can still use the same mechanism as exec-in-pod (K8sMultiplexer, but there are 2 streams for each forwarded port: data and error). Each channel will first receive its target port number as a 16-bit (little endian) unsigned integer.
Double-check the logic, but it looks to me like the process for forwarding ports is to listen locally for incoming TCP connections and, for each incoming connection, open a new WebSocket connection to forward the traffic for that connection (as opposed to using a single WebSocket connection and explicitly adding channels to that existing connection for each incoming TCP / UDP connection accepted by the local listener).
This can still use the same mechanism as exec-in-pod (
K8sMultiplexer, but there are 2 streams for each forwarded port: data and error). Each channel will first receive its target port number as a 16-bit (little endian) unsigned integer.Double-check the logic, but it looks to me like the process for forwarding ports is to listen locally for incoming TCP connections and, for each incoming connection, open a new WebSocket connection to forward the traffic for that connection (as opposed to using a single WebSocket connection and explicitly adding channels to that existing connection for each incoming TCP / UDP connection accepted by the local listener).
See the Kubernetes server-side implementation for details.