Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hooray for the Sockets Interface

blog.apnic.net

Post reply on HN
Print view View original

11–20 of 86 posts

Re: Hooray for the Sockets Interface

#11

Post by UltraSane »

asveikau wrote: post #7
UltraSane wrote: post #6

The socket interface using IP addresses instead of DNS names is widely considered to be a major mistake.

I 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.

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.

Re: Hooray for the Sockets Interface

#13

Post by jruohonen »

UltraSane wrote: post #11
asveikau wrote: post #7

Earlier quoted context omitted.

I 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.

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.

> This is a severe limitation.

Rather, it is a feature.

Re: Hooray for the Sockets Interface

#14

Post by drdexebtjl »

UltraSane wrote: post #6

The socket interface using IP addresses instead of DNS names is widely considered to be a major mistake.

Absolutely 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.

Re: Hooray for the Sockets Interface

#15

Post by ReactiveJelly »

UltraSane wrote: post #12
lelanthran wrote: post #9

Earlier quoted context omitted.

By who? I haven't seen this argument before.

https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/

Wouldn'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.

Re: Hooray for the Sockets Interface

#16

Post by drdexebtjl »

UltraSane wrote: post #11
asveikau wrote: post #7

Earlier quoted context omitted.

I 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.

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.

A 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.

Re: Hooray for the Sockets Interface

#17

Post by pjmlp »

Taniwha wrote: post #4

The article kind of misses out on the networking standards of the time - there were many of which TCP and IP were just one, most of the rest were either proprietary (DNA SNA BNA etc) and incompatible, or owned by telecoms who wanted to be able to charge per packet(X.25). TCP/IP won (IMHO) because the implementation was open source, and because no one was going to make a buck by locking others out (or charging them fo…

Same story with UNIX and C "success".

Everything else was commercial, while by being prevented to sell UNIX, AT&T was fine with giving its source code to universities for a symbolic price for sending the tapes, and the Lion's book.

It changed quite fast the moment AT&T was allowed to claim ownership, however just like with IBM and PC clones, AT&T could no longer take control over UNIX.

Re: Hooray for the Sockets Interface

#19

Post by cyberax »

drdexebtjl wrote: post #16
UltraSane wrote: post #11

Earlier quoted context omitted.

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.

A 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 t…

You 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".

Re: Hooray for the Sockets Interface

#20

Post by cyberax »

drdexebtjl wrote: post #14
UltraSane wrote: post #6

The socket interface using IP addresses instead of DNS names is widely considered to be a major mistake.

Absolutely 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.

Raw addresses could have been an advanced option, rather than a requirement for every program.
Post reply on HN