We currently do not deal with a zero-length hostname and / or zero port number in a consistent way in our ForwardedPort implementations.
ForwardedPortLocal:
* we do not bind to all local IP addresses when BoundHost is zero-length string.
* we update BoundPort with the actual port that has been assigned after starting the forwarded port.
* we do not update BoundHost
ForwardedPortDynamic:
* we do bind to all local IP addresses when BoundHost is zero-length string.
* we do not update BoundPort with the actual port that has been assigned after starting the forwarded port.
* we do not update BoundHost
By updating BoundPort (and not retaining the original value), we'll use the assigned port number as is if we'd stop and restart the forwarded port.
We should perhaps introduce a LocalEndpoint property which reflects the assigned value when the forwarded port is started, and which returns the original IPEndPoint when the port is stopped.
Still need to check ForwardedPortRemote.
Comments: ** Comment from web user: darkpixel **
ForwardedPortLocal:
* we do not bind to all local IP addresses when BoundHost is zero-length string.
* we update BoundPort with the actual port that has been assigned after starting the forwarded port.
* we do not update BoundHost
ForwardedPortDynamic:
* we do bind to all local IP addresses when BoundHost is zero-length string.
* we do not update BoundPort with the actual port that has been assigned after starting the forwarded port.
* we do not update BoundHost
By updating BoundPort (and not retaining the original value), we'll use the assigned port number as is if we'd stop and restart the forwarded port.
We should perhaps introduce a LocalEndpoint property which reflects the assigned value when the forwarded port is started, and which returns the original IPEndPoint when the port is stopped.
Still need to check ForwardedPortRemote.
Comments: ** Comment from web user: darkpixel **
+1 The ability allow the client or server to hand out a random port would be extremely useful.