What does it mean to listen on a port?
paulbutler.org
paulbutler.org
When I read that multiple processes can use the port it finally made sense to me how nginx is able to spawn so many workers. If they are listening to port 80 or 443 with SO_REUSEPORT, each worker would get a new client in a round robin fashion, effectively spreading the workload without depending on the main parent process to pipe the data to them (and back to the client), which is how I thought that it was working.
The funny thing about this submission was that when I read the title I somehow thought I was reading it on Stack Overflow and was expecting a noob asking this question and didn't know what kind of answers I was about to be confronted with and if I should get excited to see a really good one.
Then, while in the article, I liked how it started to raise so many issues, fanning out into these special cases which really made it a valid question to ask what it does mean to listen to a port, how complicated it can become.
Sadly the article does not go into any detail, like showing snippets of C code from the networking stack and explaining how it is really working, how each requirement (or kluge, for that matter) is being satisfied, but it's OK, it's an article which touches the subject in an enticing enough way while having an excuse to not deep-dive into the details by keeping it in the form of a dialog between two students.
I liked it.
It’s the socket descriptor that matters. When the listen call unblocks and the thread accepts the connection it gets a new socket descriptor, it’s through this socket the subsequent read/write happens for the connection.
But, when you say "I am OK with this co-existing", you can listen to a port that is in TIMEWAIT, and quick restart is then possible.
I think this point deserves extra attention. I've been finding that in situations like this it is often much faster to read the implementation source code than try to work it out from documentation and trial-and-error. Something in this (quite realistic) vignette is that there is a lot of potential to mis-learn when the Linux source code for this is probably quite short and readable.
This is a particularly useful skill for terse languages where the source code is easy to read. And a good time to feel a bit of empathy towards the poor souls who are forced to use closed source software.
In fact, I now know what I'll be skimming through tonight ... [0]. Not short, but a lot more useful than guesswork.
[0] https://github.com/torvalds/linux/blob/master/include/net/so...
Love the article and the writing style!
/* CSS changes for fiction book style: */
.postbody p::first-letter {
margin-left: 18px;
}
.postbody p {
text-align: justify;
hyphens: auto;
line-height: 29px;
font-family: Georgia;
max-width: 683px;
margin-top: 1px;
margin-bottom: 0px;
}• Instead of `.postbody p::first-letter { margin-left: 18px }`, probably use `.postbody p { text-indent: 18px }`. (Admittedly text-indent has the downside that it is inherited by any block or inline-block children, so caution is required. Y’know, maybe in the general case ::first-letter margin-inline-start is actually handier when you’re deliberately just applying it to paragraphs, so you don’t need to worry about potential block children or inserting a `p > * { text-indent: 0 }`.)
• `hyphens: auto` will generally do nothing unless the document declares its language (which this one doesn’t), e.g. <html lang="en">. As for whether you want it anyway… eh; greedy line-breaking (which is all that any browser implements at this time) and hyphenation don’t go particularly well together, you end up with significant quantities of gratuitous and unhelpful hyphenation.
• `font-family: Georgia` is unwise, as you can’t depend on people having Georgia. (Windows should, but other platforms probably won’t, though some may alias it.) You should certainly include a fallback of `serif`. (And in this specific case, the site is already using a serif, is Georgia even worth changing to?)
• Some of the numbers are a bit odd, but I’m guessing that’s because you just implemented it in dev tools and copied it verbatim. Me, I’d use em for the text-indent (and a larger value, at that, probably 1.2–1.4em), unitless for line-height (e.g. 1.5, which is a smidgeon more), em for max-width (though if the whim took me, I might devolve to ch occasionally), and 0 for margin-top and margin-bottom (or possibly 0.5em—half a line or so actually works quite nicely on a scrolling-based medium, though I wouldn’t do it on a paginated screen or any but the thickest double-sided paper).
[0] https://www.amazon.com/UNIX-Network-Programming-Richard-Stev...
Maybe it IS that complicated, but I'm wondering if it's worth it for me as a developer that only sometimes touches on these issues, to read through it.
I skimmed that book and it does go quite deep, but also has lots of asides into C programming and Unix in general.
For example, at one point it introduces you to the idea of wrapper functions to simplify error handling. This has nothing to do with socket programming or networking. There's BSD networking history, which might not be worth your time. There's introduction to Unix commands that are outdated if you're on Linux, but "be aware that some vendors place these commands in an administrative directory, such as /sbin". There's a section on Unix standards; would you like to know what POSIX stands for? Would you like to know about 64-bit architectures? Would you like to learn about memset() and memmove(), or fork() and exec()? How about fcntl() and close(), or posix signal handling, or waitpid()? Here let me introduce you to select() and poll() and nonblocking i/o. And pthreads...
It's by no means a bad book but it's about "Unix" and "(C) programming" almost as much as it is about network programming. Depending on your background that may or may not be a bad thing but I prefer materials with narrower focus.
- More than one program can listen to the same port on the same IP address, depending on how things are initialised
- Multiple IP's can be listened to for the same port
- TCP and UDP ports are separate, so even without allowing port re-use you can have two processes listen to the same port
And lots more! For me, this was a really engaging way to learn the nuances of how the concepts of processes, ports, protocols, sockets and IP addresses relate to each other. Perhaps the format isn't ideal for everyone. Also, I have probably learned all of these concepts before, so maybe that helps.
Anyway, I bookmarked this for the next time I forget it and need to learn it again :D
edit: formatting
If you really want to understand this it'll be easy enough, connect to irc.libera.chat, join say ##linux or even better #networking and ask any question that comes to mind.
I'd advise anyone to do it; this little story is one of a kind.
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.
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.
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.
Sockets don’t look too bad compared to that
I don't care about the specific uart-level detail here.
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.
The merge work was driven by Bill Joy and Blaine Garst.
https://www.computerhistory.org/collections/catalog/10271717...
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.
The fact that a tuple (my IP, my socket, your ip, your socket, protocol) is used instead of COM4 is just a detail.
write(fd, "hello", 5);
write(fd, "hello", 5);
TL;DR:
- the OS maintains a hash map mapping port/IP/protocol/protocol-version to lists of sockets
- there's a scoring algorithm that determines which socket wins, based on specificity of how the socket(s) were bound
- if multiple sockets are bound with SO_REUSEPORT, things are routed based on a hash of the source/destination address/port, presumably so packets from a single client aren't split between different handlers - essentially, simple zero-backpressure load balancing
- read the article for nuances of when and how to use this, especially performance considerations about pre/post fork
- consider adding TL;DR segments like this, whether you're writing discovery fiction like the OP, or technical deep-dives like the link in this comment. Different readers will prefer different formats, but everyone benefits from having the option to consume an abstract before reading lengthy nonfiction prose!
Don't get me wrong -- all of this functionality is useful in some context, and it is there for a reason. We cannot radically simplify the kernel without making it less useful. But it is still somewhat sad there is so much essential complexity even in simple things like "listen" call.
It's their stack of hacks.
I’m pretty sure you could design a spec-compliant alternative which didn’t do any of these things, if you really wanted to.
In my experience, the network layer is often way better-designed, more reliable, more interoperable, and less hacky than most OS abstractions built on top of it.
The storytelling style, however is very difficult to skim. It really requires reading dialogues and actions.
However, it's a Sunday afternoon, raining and there's thunder in the background. It's the perfect style to relax and enjoy.
The goal isn't to embed information in meaningless dialogue, but to walk the learner through an entire thought process rather than just presenting the finished result. Or to use one of tech's favorite expressions, to construct an idea from first principles.
When I started out, a port was (and still is) just a designated memory location, and address, where some process (like a NIC driver) can write byte(s) into it. 'Listening' on a 'port' just meant the memory location is checked by a piece of code either through polling or interrupt driven. The interrupt is triggered by the same process that placed the data into the mem location.
Abstraction married to time is a is the enemy of knowledge.
It is kinda fun to work directly at IP level and not use TCP or UDP at all. I highly recommend giving it a try.
Possibly dumb question: if you're not using ports (because you're not using TCP at all), what does routing look like, in terms of this article? How does the kernel decide which traffic goes to application A and which traffic goes to application B? Or is all traffic directly visible to each application, if they aren't bound to a port? Can you bind to a specific IP, or just to an interface?
Not sure of the implementation details, but in principle the same logic about specificity of socket binding could be done by the kernel when deciding which socket to actually send the data to. Any other logic (CRC validation, packet ordering, confirming packets have been received, MSS etc.) are all disabled, you just get the raw packet as it was received on the wire, based on the IP headers (an the same happens when you send a packet on a raw socket).
Most of that address space is used to allow for stateless autoconfig, though. It would be certainly possible to fit in port multiplexing, but you'd have to make a trade-off in increasing collision risk, depending on how you do it. Or go back to static addresses or DHCPv6.
If a packet hits a pocket on a socket on a port,
And the bus is interrupted as a very last resort,
And the address of the memory makes your floppy disk abort
Then the socket packet pocket has an error to report!
This seems to confirm: https://lwn.net/Articles/542629/
Maybe the exact behavior varies by platform. I've never used it on Windows.
Yes, that was the case. Also I probably confused SO_REUSEADDR, which in Windows is implemented quite differently, with SO_REUSEPORT. Anyway, I can confirm that on Windows (2000) I could open N programs whose receiving socket was bound on the same address:port and all of them would receive a copy of the transmitted datagram. If say I run 5 copies of the same agent, all of them would display the same data. Those were stand alone applications without any shared memory, so apparently the system made a copy of the buffer for each socket. I'm not sure however if I tested this particular behavior also under Unix, since I needed it only on the graphical interface, but on Windows it definitely worked.
Ahhh, the joys of "portability"...
> This option permits multiple instances of a program to each receive UDP/IP multicast or broadcast datagrams destined for the bound port.
It makes way more sense to think of an IP address as the entire “address”+port tuple. When you look at it like that, so many aspects of computer networking get simpler. First, we think of every computer on a network as having a range of addresses - usually 65536 of them. But that’s an arbitrary choice that could be adapted in lots of ways. Every connection directly connects two IP addresses - which is way simpler than what we do now. DNS should associate a name with an address - including what we currently call the port. That way we wouldn’t need special application specific port assignments. And then we wouldn’t need SNI and all that - because computers could have a bunch of fully process-isolated web servers, just listening on different incoming address+port tuples.
Obviously we can’t change tcp/ip, but parts of the tcp/ip infrastructure already work this way - but we’re lacking the language to talk about it.
And from an address perspective, its better because we end up with much more flexibility around how our networks are designed. Want to use 1 public IP address with 10k web servers? Now you can! Want a single machine to handle 10M outgoing socket connections? Sure - just allocate more addresses from your pool.
You can already do some of this stuff right now, but its awkward to reason about because of how ports and addresses interrelate. It'd be simpler and easier if we just think of the (address,port) tuple as a single address entity.
In many way's it's a very historical thing, back when TCP/IP was one of many competing network architecture (early 80s) most of the competing architectures did it the other way (there was only one port at that level and protocols ran under that). Is one better than the other? probably not much - TCP/IP won (IMHO) because they understood datagrams vs. virtual cicuits - they didn't plan on charging for TCP or IP level retries.
In effect, a machine would have its own internal network with individual, publicly addressable nodes representing various receivers.
Just imagine how virtualisation/containerisation would get simplified.
> It makes way more sense to think of an IP address as the entire “address”+port tuple.
There's already a term for that - they call that a socket.
SNI has to do more with the "Host:" header of HTTP and the behavior of HTTP servers than anything else. Web servers started using that due to IPv4 address exhaustion and the need to host multiple "sites" on a single IP. IPv4 scarcity created a lot of twists in the end-to-end design, including this and NAT.
I think it would be cool if DNS gained the explicit capability to resolve names not only to IP addresses but also destination port. Not sure why it didn't. Certain apps can use SRV records or whatever but it's not standard.
Seems more logical to just do the IP+port tuple. Maybe having TCP and UDP on separate port "namespaces" is the confusing part here and someone above mentioned could be simplified.
The real casualty from merging IP addresses and ports, however, is that it would no longer make sense to listen on a certain port on "any" address/prefix (::/0); if there is more than one interface or prefix assigned to a host and an application wants to accept incoming connections from each of them it will need to listen on multiple sockets, and open and close those sockets as prefixes are added or removed.
This is something I really agree with. For an example that does naming right, Google's internal BNS addresses[0] in fact resolve to a host IP address plus port. Much more convenient because conceptually now a single piece of information is needed to identify a specific running instance of an application on a machine.
or alternatively IPv6 Multicast Addresses: https://www.iana.org/assignments/ipv6-multicast-addresses/ip...
Of course, they are not really used that way nowadays... except by firewalls maybe, so even more stuff is moving to 80/443.
They are kind of useful sometimes if you consider port < 1000 privileged, although that's also quite limited.
https://www.goodreads.com/book/show/17255186-the-phoenix-pro...
Okay, that was pretty good. I've long since lost track of the number of times I've had this exact exchange.
There doesn't seem to be a Manga Guide to TCP/IP yet.
Personally, it's divisive for me too --- if I'm looking for specific information, this gets in the way; if I'm looking for "edutainment", then it fits.
Like if you can pick any story, why make it about two people in a study hall, studying and directly asking each other the question? It could be a story about some rogue hackers, international spies, or the characters could be ducks rather than humans, or you could tell it from the perspective of a sentient computer or application... So if you are going to make it into a fictional story, you might as well make it a fun fictional story (either by the premise or by a character!).
As in telling the true story which is probably “I wondered how ports work, then I did this, then I wrote this script, then it had an unexpected result”, which still reads as discovery to an audience (but is the authentic and true story).
IMO Readers will find a true story interesting if told with authenticity and passion.
For fiction, you generally need ‘an ununsual thing’ in the story that happens that breaks it away from normality.
I think this treads the awkward space inbetween - it’s made up (so no authenticity) but that authenticity isn’t replaced by something ‘unusual’ that drives the story forward.
> Maybe the prose went a little further than it needed to, or as you suggest not far enough.
I think this is right - although I don’t think there is a happy medium between those points. I think you can go in either direction (further or less), but straddling the middle is the tough bit.
Also to get more page length from Google and to avoid duplicate content issues.
(Edit: someone else already posted that further down - doh)
> “So when you listen on a port, you’re really listening on a combination of a port, an IP, a protocol, and an IP version?”
> “Yeah, unless you listen on all local IPs. And if you listen on all IPv6 IPs, you also listen on all IPv4 IPs, unless you specifically ask not to before you call bind.”
> “Right. So the operating system must have, like, a hash map from a port and IP pair to a socket, for each combination of TCP or UDP, IPv4 or IPv6.”*
> “To a list of sockets”, Liz corrects. “Remember how I could listen on more than one?”
> “But it also has to handle listening on all ‘home’ IPs, and to be able to find a socket listening on IPv6 from an IPv4 IP.”
You can think of the port number as the second half of your IP address. As far as the networking goes, an IP address and a port number are basically the same thing. The port number is just the lower bits of the "combined IP address".
And it's worth mentioning that IP doesn't have ports. You don't take a port and then divide it into TCP and UDP use. TCP and UDP each independently build their own version of ports.
Great article, enjoyed it.
I get the idea of presenting concepts in a more natural flow and smuggling in some spaced repetition, but the whole story just felt extremely forced and artificial to me, sort of like a drawn-out sequence of expospeak.
There has to be a better way to include spaced repetition and discovery in teaching.
Edit: Note this correction by Michael Nielsen: https://news.ycombinator.com/item?id=30325048
Fictional kingdom discovers Trigonometry out of necessity.
I also like that the story encourages experimenting and testing out your mental models, like Liz did.
It's just the particular way they discover things that feels forced to me. The story is all about them coming to their own conclusions and thinking up their own experiments, but - it being a story - you know, it's actually all guided beforehand.
Maybe what irks me is that this concept of a character discovering "on their own" some ostensible deep truth (which is really just the author's personal opinion about something) has been used for a lot of worse reasons in other stories - even though, in this case, the "truth" is perfectly harmless and beneficial.
Anyway, it's always easier to criticize than to create, so I won't say I really have better ideas of how to do it.
I found this video from Veritasium that explains it: https://www.youtube.com/watch?v=rhgwIhB58PA
Which is all interesting, but mostly just disproves VARK and similar approaches to describing differences in how people learn. There are still so many different ways to teach someone something, they're just much more holistic ways of teaching than the simple VARK split. That some people learn better from X course of teaching and others learn better from Y course of teaching still seems likely to me(admittedly, just pulling from personal experience and the anecdotes of others on that ). That we don't have a neat way to categorize that might just mean it's too messy to do so, or could mean we just haven't figured out the right way to look at it yet.
Even if we assume that people all learn the same way, good learning integrates new facts or concepts into ones pre-existing mental model of the world. Not everyone has the same mental model - of this I am certain. Sometimes new information just hangs on the existing model, and sometimes the existing model needs to be updated. This can make the process seem like everyone learns differently, since different explanations can make more or less sense depending what's already in their head.
On top of that, I think some people have (maybe inherently) very different abilities in things like visualization, memorization, vocabulary, etc... So yeah, I think everyone learns differently even if at some neuronal level it's all the same.
This is actually a failure of discourse in many areas of life – "X is hard to solve or haven't thought about it, so it must be that X is different for everyone". Nutrition, Product Reviews, etc. I've learned over years that anyone that claims "X is different for everyone" is most likely exhibiting a defeatist attitude.
The universals about learning, which I've taken away from the discussion, is that active learning and recall is generally effective, while passive learning (e.g. re-reading) is less effective. A good research paper that covers this (which I've mentioned in that discussion) is called "Improving Students’ Learning With Effective Learning Techniques: Promising Directions From Cognitive and Educational Psychology" [PDF]: https://pcl.sitehost.iu.edu/rgoldsto/courses/dunloskyimprovi...
I liked it, for what it's worth.
Yeah, I'm really glad this was the top comment. That style of journalism has become all pervasive today, and the grotesque self indulgence of it is honestly sickening. I refer to it as "college term paper journalism", because they all read like a sophomore English 102 essay.
It's way too long since I read it, so I can't really compare, but I remember that the whole topic was actively discussed and reflected in the novel. That's something different.
Like, Sophie being a character in a novel was an important plot point of just that novel, if I remember correctly.
You can see there's no dialogue; the idea is to frame an article as "how might you discover/invent this concept on your own", rather than just directly explaining how a thing works. You are given a fictional goal, and you "discover" the subject matter by building iterative solutions.
people are often helped by metaphor (e.g. "a port is like a mail slot in a huge mailroom...") but i feel like this "discovery fiction" thing is like an inverse version of that... it allows your brain to be creative when thinking through the topic but just focused on the wrong part of the explanation.
I can imagine TFA re-written without the dumb story being really good. It makes use of spaced repetition, and it does a good job of introducing one piece of information at a time. But I agree; the story part of it is stupid.
To be sure this article isn't in the same league at all. Great teachers are scarce no doubt because few are gifted with the requisite raw talent. It implies you're right, it's hard to produce top-quality written teaching material, after all excellent examples are uncommon, even vanishingly rare.
For myself - and I know others respond very differently - I usually want everything in an essay to serve the overarching point. So I find fictional asides pretty distracting. There are exceptions: Imre Lakatos did it well in "Proofs and Refutations", and Douglas Adams did it well too. But it's tough to pull off!
Other great examples (though in a whole other league) are the phoenix project and the unicorn project, where the characters learn along the way.
Of course the learning and story is "guided" by the author. Every story ever written was.
But this was such obtuse writing that was painful to read.
I recommend a less clunky narrative based format.
If we're exploring the mysteries of the Universe, stories help, but our own arbitrary creations? They are just tools. They should be simple, robust, anti-complex and as mundane as we can make them. T
Nothing is keeping you from writing it the way you suggested.
The only thing I thought at the end was: "yeah, the whole thing should be torn down and redone from scratch". Which of course isn't ever happening, right?
Kit Marlowe was listening on a port down by his favorite tavern, planning on skipping out on bail, when he was knifed to death.
This style reminded me of GEB a bit and I enjoyed it.
"Write in a way that draws the reader's attention to the sense and substance of the writing, rather than to the mood and temper of the author. If the writing is solid and good, the mood and temper of the writer will eventually be revealed and not at the expense of the work. Therefore, the first piece of advice is this: to achieve style, begin by affecting none — that is, place yourself in the background."
> In the U.S. copyright law doesn't protect "a mere listing of ingredients," but "where a recipe or formula is accompanied by substantial literary expression in the form of an explanation or directions... there may be a basis for copyright protection."
This is from an article about a tool developed to extract recipes from their blogs:
https://www.eater.com/22307633/why-are-people-mad-at-recipea...
As a person who doesn’t do much networking, I appreciated the context.
I wonder if the people who didn’t like the post style are networking experts who are already steeped in this stuff?
Anyone care to comment if the fall into either group?
“Hmm that doesn’t work, what about X”
<code>
“Oh but that didn’t do what I wanted. What if we added Y and Z”
<code>
I know a thing or two about networking and didn't really learn anything new from the article.
And I don't really like the style, but I don't feel like my expertise with networking plays much into it.
Why didn't I like it? Hmm, first of all, I skipped the italic blurb and jumped straight in. So at first I didn't know I was reading fiction. It sounded like story time, as in a story of something interesting that actually happened, and for which you may need to give a bit of context.. I don't have a great example in mind but think something like the 500-mile email (https://www.ibiblio.org/harris/500milemail.html). That's the kind of story I expected I was getting into. And then I was disappointed that there was no story.
Once I got over that and looked back.. well, one obvious thing that's missing for me is motivation. “Yeah, I know that, but how?” Liz says. Why does she care? Why should I care?
I immediately got the same vibe that I get when I come across someone with an X-Y problem and they're the stubborn kind who refuse to explain why or what they're actually trying to find out. Or when I come across someone who's curious but trying to pass the burden onto someone else (kinda like a help leech except that they don't even have any concrete problem they need help with). It wouldn't be the first time I've said on IRC something like "Sorry, I don't know. If you really want me to read the kernel code for you and tell you how it works, I might do that later tonight but I figured you could satisfy your own curiosity." Someone wants to know something but there's no real motivation for the next person to care. I guess I kinda feel how I imagine Tim feels: he can guess what the OS might be doing, but he doesn't have motivation to find out more.
And then there's the fiction-fluff that doesn't really do anything for me. Liz and Tim aren't interesting, there's not much personality, and even if they had personality, there's not much reason to care; they're just random nobodies. The setting isn't interesting. I don't care if there's a coffee shop because the coffee shop also isn't a key element of the story; arguably, there are no key elements. There isn't anything exciting going on, Liz just wants to know how Linux demultiplexes TCP and UDP. So all the fluff feels superfluous and forced.
It could work if there was an interesting story. A reason to build something, a reason to find something out, a reason to poke the kernel around a bit. And in that case, you wouldn't need so much "fluff"; the narrative could support and enrich the story (explain things and continue to add motivation) rather than just pad it. Writing that sort of educative story is really hard though.
Maybe in the next chapter Tim can confess his feelings for Liz while they learn together about Unix Domain sockets?
"In the corner of the student union building there is a coffee shop, and in the corner of the coffee shop are two students. Liz taps away at the keyboard of the battered hand-me-down MacBook her brother gave her when she moved away to college. To her left on the bench seat, Tim scrawls equations on a coil-bound notebook. Between them is a half-empty cup of room temperature coffee that Liz sporadically sips from to stay awake.
Across the room, the barista looks up from his phone to glance around the shop. ..."
If he was a good writer, maybe he could have made it work. But this reads like a "write what you did yesterday" assignment handed in by a 12 year old. If even.
> you never would have seen it
On the contrary -- I clicked it only because of the title. But I stopped reading after the first paragraph, so I still don't know what does it mean to listen on a port, exactly because of the style, too bad for me. :)
But I strongly support your right to write any style you want, I'm avid supporter of authors' "right to burn".
Personally I want the gory technical details. This reads like those recipe sites that give you an unnecessary life backstory.
The gore may be less approachable, but I'd say the overall effort to understanding the material is less.
The moderation comments I post are for sure repetitive and tedious. The justification for them is not that they're interesting in their own right (they aren't! and they're even more tedious to write than to read). It's that without them, HN would be globally worse off. They're an out-of-band feedback channel forming one component of the system by which the forum regulates itself.
You can compare them to medicine which is toxic but which one takes anyway because the alternative is worse.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...