5 ms·
The socket interface using IP addresses instead of DNS names is widely considered to be a major mistake.
by UltraSane 3mo ago
The socket interface using IP addresses instead of DNS names is widely considered to be a major mistake.
- asveikau 3mo agoI disagree with this. Separating lookup from connect(2) or sendmsg(2) is cleaner. If an application doesn't care about the difference, most people are using higher level APIs built on top anyway, and most of those will provide a quick way to hide DNS details from you.
- UltraSane 3mo agohttps://blog.ipspace.net/2009/08/what-went-wrong-socket-api/ https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/ A DNS name can have a LOT of A records associated but a socket has to pick one. This is a severe limitation.
- jruohonen 3mo ago> This is a severe limitation. Rather, it is a feature.
- UltraSane 3mo agoHow so?
- jruohonen 2mo ago> How so? Standards as well as all manual pages and other documentation say that getaddrinfo() should be called via a loop by clients. And results show that almost all clients indeed do that. Therefore, on the server-side, you can do round-robin DNS, randomization (as suggested by the post linked), fall-backs, CDN things, and many other things.
- UltraSane 2mo agoStandard TCP maps connections to IP addresses. If your IP changes, the connection drops. A secure cryptographic Session Layer maps connections to your unique device ID. Imagine if the functionality of something like tailscale was actually built into TCP/IP. This is what the missing session layer should have been.
- drdexebtjl 3mo agoA socket has to pick one, but your application doesn’t. You can hedge your bets and open a connection and send data to _all_ of them, and pick whichever returns faster. This of course requires you to know about the application-layer protocol. For HTTP, you need to restrict this strategy to GET methods, for example. Hence why it can’t be part of the socket interface. You can always build higher level abstractions on top of sockets if you need them.
- cyberax 3mo agoYou absolutely can establish multiple TCP connections for POST methods. You just can't send any _data_. This is even used by browsers, this trick even has a slightly creepy name: "Happy Eyeballs".
- drdexebtjl 3mo agoThat’s true for HTTP. TCP does not require that the act of connecting must be pure, so you cannot indiscriminately apply Happy Eyeballs at the socket API level.
- zbentley 3mo agoI suppose, but the number of applications for whom a successfully-negotiated bare socket connection (with no TLS or data exchanged) is side-effectful to the point that this causes problems is pretty darn small. I'm sure there are some terrifying counterexamples, but they have to be part of a tiny minority, right? More concerning is the risk of exhausting server socket resources when probe-based connects don't hang up quickly if they don't want to use a connections. Lots of servers/load balancers aren't well-tuned to force-close connections if the first byte doesn't arrive within a short time.
- drdexebtjl 2mo agoI agree. But we couldn’t have possibly guessed this in the 80s. Instead we converged on a very simple primitive that makes no such assumptions and can be composed into a wider variety of high level abstractions in user space.
- zbentley 3mo agoI'd actually say that the original sin of the socket API was taking DNS in higher-level connect methods at all. Users should have to separate the act of address lookup from the act of opening a connection every time (and could write the 5loc utility function to hide that split if they want). I say that not out of purity concerns, but because of how DNS and TCP work. DNS multirecord selection (or not) should be up to the user. DNS timeouts should be surfaced granularly and differently from e.g. TCP SYNACK timeouts. Once a TCP stream is open, if a novice user opened it conceptually to a domain rather than an address, there's no intuitively correct answer to what happens if the domain's resolution changes while the socket's connected.
- inigyou 2mo agoWhen it was written I don't think they had DNS. Maybe they had hosts files maybe not.
- asveikau 2mo agoImagine if handling that were a kernel feature completely hidden from you and there was no way to replace it in user mode, or even have visibility into its failure modes. I'd say that's worse.
- UltraSane 2mo agoTelling the socket the IDENTITY of the host you want to reach and abstracting away all the details of how to reach it is exactly what the missing TCP/IP sessions layer is supposed to do. By tightly coupling the session layer to explicit Layer 3 network routing parameters (IP addresses), the classic socket API failed to separate a host's identity from its physical location.
- asveikau 2mo agoQuestions of identity are established at a higher level in user mode by TLS. Pushing all that into the other side of the kernel interface again seems not great.
- UltraSane 2mo agohttps://en.wikipedia.org/wiki/Locator/Identifier_Separation_Protocol https://en.wikipedia.org/wiki/Locator/Identifier_Separation_... I've used this in networks and it enables amazingly easy endpoint mobility.
- tremon 3mo agoIt's not just about separating lookup and connect: the fundamental stream abstraction is a point-to-point connection. It's possible to construct one-to-many connections on top of that, but it adds a lot of complexity on both sides. Doing it the other way around (emulating one-to-one connections on top of a one-to-many abstraction) means burdening simple connections with a lot of unnecessary complexity.
- lelanthran 3mo agoBy who? I haven't seen this argument before.
- UltraSane 3mo agohttps://blog.ipspace.net/2009/08/what-went-wrong-socket-api/ https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/
- ReactiveJelly 3mo agoWouldn't this add a ton of complexity for anything that extends DNS, like DoH, DoT, VPNs, firewalls, etc., and you'd still need to connect by IP for LAN connections or P2P? Cause what you're asking is not just to do the regular DNS lookup inside `connect`, but to have the OS manage roaming and continuously updating DNS while the connection stays up? I don't know about that. I don't know. That's a lot of complexity deep in the kernel and ossified. I'm happy with the QUIC solution that allows you to migrate IPs and it's all userspace. It would be very hard to evolve a network protocol that had to be crammed into 3+ different kernels.
- UltraSane 3mo ago[dead]
- drdexebtjl 3mo agoAbsolutely not. You can have sockets without DNS. You can pick whatever strategy you want when there are multiple A records. You can use SRV records instead. And most importantly imo, it mirrors the listening API.
- cyberax 3mo agoRaw addresses could have been an advanced option, rather than a requirement for every program.
- UltraSane 3mo agoExactly
- GoblinSlayer 3mo agoUnix sockets kinda already connect by name.
- inigyou 3mo agoUse getaddrinfo
- drdexebtjl 3mo agoI feel like this wouldn’t be a problem if we had decent APIs for name resolution (separate from sockets) instead. The ones we have suck or are non-standard.
- cyberax 2mo agoNope. They have to be coupled for the Happy Eyeballs to work. Another option is for sockets to accept multiple addresses and address families in "connect" calls, so that only one connection wins.
- drdexebtjl 2mo agoNo, they don’t. They aren’t coupled today, and applications implementing Happy Eyeballs work perfectly fine on top of sockets and a DNS client.