-
Notifications
You must be signed in to change notification settings - Fork 894
fix: use fake local network for port-forward tests #11119
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.
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,50 @@ | ||
package clibase | ||
|
||
import ( | ||
"net" | ||
"strconv" | ||
|
||
"github.com/pion/udp" | ||
"golang.org/x/xerrors" | ||
) | ||
|
||
// Net abstracts CLI commands interacting with the operating system networking. | ||
// | ||
// At present, it covers opening local listening sockets, since doing this | ||
// in testing is a challenge without flakes, since it's hard to pick a port we | ||
// know a priori will be free. | ||
type Net interface { | ||
// Listen has the same semantics as `net.Listen` but also supports `udp` | ||
Listen(network, address string) (net.Listener, error) | ||
} | ||
|
||
// osNet is an implementation that call the real OS for networking. | ||
type osNet struct{} | ||
|
||
func (osNet) Listen(network, address string) (net.Listener, error) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How would we handle situations where you might need to configure dialing via Maybe we don't have such use-cases at this time but I'm concerned since we are introducing the field on clibase, which suggests it's the only way one should establish network connections (compared to injecting it into the specific command that needs it). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Add a
I'm not sure what you mean here. How would that suggestion be different than what I've implemented? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The idea here is that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I suppose that could work, injecting resolver/dialer for the in-mem stuff 👍🏻.
With that parenthesis, I basically meant not putting the field in clibase/inv until there are more use-cases, i.e. keeping it port-forwarding only for now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure how we could keep it port-forwarding only without a major refactor. The command handler only gets an There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's also |
||
switch network { | ||
case "tcp", "tcp4", "tcp6", "unix", "unixpacket": | ||
return net.Listen(network, address) | ||
case "udp": | ||
host, port, err := net.SplitHostPort(address) | ||
if err != nil { | ||
return nil, xerrors.Errorf("split %q: %w", address, err) | ||
} | ||
|
||
var portInt int | ||
portInt, err = strconv.Atoi(port) | ||
if err != nil { | ||
return nil, xerrors.Errorf("parse port %v from %q as int: %w", port, address, err) | ||
} | ||
|
||
// Use pion here so that we get a stream-style net.Conn listener, instead | ||
// of a packet-oriented connection that can read and write to multiple | ||
// addresses. | ||
return udp.Listen(network, &net.UDPAddr{ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are we sure we want to use pion for UDP in all CLI usage going forward? (I understand this is mainly used by port-forward, so this is mainly a future concern about making assumptions based on one use-case). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure, no. We can always refactor later if this doesn't meet the future use case. Putting UDP into its own method makes faking this interface harder/more complex. |
||
IP: net.ParseIP(host), | ||
Port: portInt, | ||
}) | ||
default: | ||
return nil, xerrors.Errorf("unknown listen network %q", network) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This package is no longer maintained (repo archived). We should consider switching to
github.com/pion/transport/v2/udp
if we still need the library.