21–30 of 86 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Sockets won over over-engineered monstrosities like STREAMS or X.whatever And yet, sockets are a terrible interface. They don't provide a way to get the details of the underlying connection for features like migration, checkpointing, or introspection. E.g. there is no way to get the current sequence number for TCP (there is "connection repair" mode now, but it's Linux-specific). Well, you can say that sockets abstrac…
Earlier quoted context omitted.
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 de…
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…
[1] https://en.wikipedia.org/wiki/FTP_Software [2] https://en.wikipedia.org/wiki/NetManage
I have two complaints about sockets: 1, bidirectional sockets probably should've been ≥2 fd's, not 1. 2, non-blocking semantics and poll/select suck. Can't blame anyone in 1983 for not getting "async I/O" right since we're still struggling; at least now we have some decent answers (like io_uring on Linux.)
Sockets won over over-engineered monstrosities like STREAMS or X.whatever And yet, sockets are a terrible interface. They don't provide a way to get the details of the underlying connection for features like migration, checkpointing, or introspection. E.g. there is no way to get the current sequence number for TCP (there is "connection repair" mode now, but it's Linux-specific). Well, you can say that sockets abstrac…
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…
While TCP/IP was open source and not controlled by any 1 vendor, quite a few companies made good money from selling TCP/IP stacks and won themselves billion dollar valuations in the process[1][2]. Of course this was during a time when Microsoft saw no point in including an IP stack with their OS, or indeed much point in connecting to the Internet at all! Some of the younger readers may find these things hard to belie…