Accept hostnames for tcp:, tcp-listen:, udp:, udp-listen: #56
Conversation
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
andersk
force-pushed
the
net-hostnames
branch
from
4b11dbe to
a92d4af
Compare
| pub fn resolve_addr( | ||
| addr_str: &str, | ||
| ) -> impl Future<Item = SocketAddr, Error = Box<dyn std::error::Error + 'static>> { | ||
| // TODO: resolve asynchronously |
There was a problem hiding this comment.
Is it really needed to be resolved at connecting time, not just once at argument parsing time?
There was a problem hiding this comment.
I think it is: when running websocat as a daemon, it shouldn’t need to be restarted just because a remote DNS name changed. Additionally, one might want to point websocat at a service using DNS load balancing.
There was a problem hiding this comment.
Tardiness in DNS reply may not only delay establishing a new connection, but also suspend all unrelated neighbour connections - websocat is mostly single-threaded.
There was a problem hiding this comment.
Yeah, until we get async DNS, that’s a tradeoff. But this design allows the user to make that tradeoff. They can always choose to provide an IP address, or to install a local caching resolver (which will do the job much better than we would—sharing the cache between all apps on the system, respecting TTLs, and so on).
| .to_socket_addrs() | ||
| .and_then(|mut addrs| { | ||
| addrs | ||
| .next() |
There was a problem hiding this comment.
That would be a welcome extension.
|
Note: I remember doing similar change (but more elaborate, supporting multiple addresses and fast fallback) in "websocket_lowlevel" branch where websocat 2.0 is cooking. Maybe it's worth backporting it to websocat 1... |
vi
force-pushed
the
master
branch
2 times, most recently
from
00113dc to
9ab5e4a
Compare
2 participants
No description provided.