Hacker News Reader

Comment by GeorgeTirebiter | Hacker News Reader

Does anybody else dislike the socket interface abstraction? To me, an individual TCP port + IP is, effectively, giving me a 'virtual uart'. Instead of saying COM4 or whatever, you say tcp port 12345 IP address 6.7.8.9

Similar thing for ranges of IP address, except in that case, the 'listener' has to figure out which 'virtual uart' to act upon. In that case, the OS splits the 'virtual uart' assignment with the server listening to a range of address.

Sockets seem unnaturally messy to me. Maybe I'm ignorant.

View on HN

Sockets are ridiculously complicated as APIs go. STREAMS [0] was a much nicer networking API but sockets won because in the late 90s sockets were faster (supposedly) and STREAMS became untouchable because they were part of the SCO IP fiasco. Now that SCO is history it might be worthwhile to revive STREAMS and explore it again.

[0] https://en.m.wikipedia.org/wiki/STREAMS

Apparently there is an implementation of STREAMS on Linux here http://www.openss7.org/streams.html

Additionally as I recently learned when Sun made the deal with AT&T, STREAMs were not deeemed relevant to offer on Solaris.

The merge work was driven by Bill Joy and Blaine Garst.

https://www.computerhistory.org/collections/catalog/10271717...

The COM4 endpoint only exists inside that one computer. There is one, and only one COM4 in that one computer; anybody who wants to read or write from/to it knows how to identify it.

A socket is reachable from other computers, so it must have a network address of some kind associated with it. The process that owns the port may want to refuse connections from another computer, so there has be a step in which the receiver accepts an attempted connection.

COM4 can essentially never reject either a reader or a writer.

Yes. It is bad. And it’s warped programmer brains for decades now. If you want to have some fun and design a better interface, go grab a direct kernel-bypass layer 2 NIC interface and learn how much better things could have been. Unfortunately, the sockets api isn’t going away. But, on the positive side, it’s one of the most portable OS interfaces out there.

I switched from hardware engineering to software engineering, and the socket abstraction (as well as the TCP bytestream abstraction, which appears to have been part of the inspiration for how sockets work) seemed absolutely nuts to me. Kernel bypass style queues make a lot more sense from first principles.

I remember some of this on Windows when I was implementing a prototype DNS that could saturate a 10G link.

There were two components, Receive-Side Scaling and some special user-mode thing. RSS would load-balance 5-tuples onto different cores somehow, triggering interrupts on the right core for that stream. If you were careful with the driver stack you could have zero-copy all the way to user mode, where there was some magic that let you dispatch into user mode and read packet data from a ring buffer.

Gave me an appreciation for how a single machine is made of lots of pieces, and how frustrating it is to chase perf.

The socket API is slowly going away though. On iOS devices the socket API simply isn't good enough to deal with complicated things like transitioning from cellular radio to Wi-Fi. Apple has discouraged the traditional socket API and encouraged their own CFStream/NSStream API for a long time.

> To me, an individual TCP port + IP is, effectively, giving me a 'virtual uart'.

It's not, though. A single destination can have an arbitrary number of sockets/uarts connected to it. You can server on port 80, and accept a connection from 127.0.0.1 and from 192.168.100.23 and from 10.98.54.4 and from anywhere else on the internet and have them all operating simultaneously. And in fact each destination port can have many connections to the same IP and port combination, discriminated by the source port which is a number the programmer generally never sees (unless you bind it specifically, it's automatically assigned).

It's exactly that kind of almost-right-but-not-quite mental misrepresentation that the article is trying to address.

I don't think you fully understood my point. What I'm saying is that when any comm happens between network endpoints, it's essentially identical to a uart stream.

The fact that a tuple (my IP, my socket, your ip, your socket, protocol) is used instead of COM4 is just a detail.

Write into a uart looks like this:

    write(fd, "hello", 5);

write into a connected tcp socket looks like this:

    write(fd, "hello", 5);

Sounds like you have what you want?

UARTs have 7 vs 8 bit, parity negotiation, speed negotiation and all other manner of arcane config that has to be exactly perfect for anything to flow.

Sockets don’t look too bad compared to that

I'm not sure you quite understood my point? I'm not claiming that uarts are the end-all, be-all. What I am saying is that, even with the features of 'sockets' e.g. being able to be a 'server', ultimately, when data transmission happens, it's as if you have a virtual uart.

I don't care about the specific uart-level detail here.

write() and read() work on a connected socket fd just as they work on a uart. So I don't really understand what the problem here is?

Of course you have datagram protocols and recvmsg() & co, which are useful precisely when you're dealing with something that does not looks like a uart.

As OOP is to languages, Sockets, to me, is to networking.

Since I read from left to right its major:minor to me. The major one is the IP, since it can have 65535 ports. Its unfortunately not the same with dates. I prefer ISO 8601. Major:minor:micro (or whatever you call it with 3).

wish we had plan9 dial interface instead of the BSD sockets interface: https://9fans.github.io/plan9port/man/man3/dial.html

Is golangs `net.Dial` related to this? I was wondering why they named it this way.

Go is very much a descendent of Plan 9. It’s written by Rob Pike of Bell Lab / Plan 9, is heavily inspired from languages such as Alef https://en.wikipedia.org/wiki/Alef_(programming_language) which ran on Plan 9 and, if I recall correctly, Go’s original compiler was basically a modified compiler for one of this Plan 9 systems languages (to enable Pike et al to speed up the release of version 1.0).

What is a virtual uart?

Reply on news.ycombinator.com