[HN Gopher] What does it mean to listen on a port?
___________________________________________________________________
What does it mean to listen on a port?
Author : paulgb
Score : 352 points
Date : 2022-02-13 18:01 UTC (4 hours ago)
(HTM) web link (paulbutler.org)
(TXT) w3m dump (paulbutler.org)
| GeorgeTirebiter wrote:
| 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.
| xorvoid wrote:
| 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.
| dreamcompiler wrote:
| 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
| zokier wrote:
| Apparently there is an implementation of STREAMS on Linux
| here http://www.openss7.org/streams.html
| Fordec wrote:
| As OOP is to languages, Sockets, to me, is to networking.
| Fnoord wrote:
| 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).
| tezza wrote:
| 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
| Cloudef wrote:
| wish we had plan9 dial interface instead of the BSD sockets
| interface: https://9fans.github.io/plan9port/man/man3/dial.html
| qwertox wrote:
| Is golangs `net.Dial` related to this? I was wondering why
| they named it this way.
| PaulDavisThe1st wrote:
| 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.
| enchiridion wrote:
| Interesting divide on the writing style here.
|
| 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?
| dmoy wrote:
| I don't do much networking, and I found it difficult to parse
| information out of this.
| [deleted]
| ninth_ant wrote:
| It would be improved by changing the framing from a discussion
| to singular persons internal dialogue showing progression and
| train of thought. I've used this before in a work context to
| explain complex debugging issues.
|
| "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>
| jollybean wrote:
| It'd be ideal to have a very succinct and clear 3 sentence
| articulation. Followed by maybe a couple of examples.
|
| 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
| htk wrote:
| It would be _your_ ideal.
|
| Nothing is keeping you from writing it the way you suggested.
| wonnage wrote:
| I have to admit I'm not a fan of "discovery fiction" as presented
| in this post, but reading Michael Nielson's linked post and some
| of his examples (e.g https://michaelnielsen.org/ddi/why-bloom-
| filters-work-the-wa...) I think the idea is great if executed
| well.
|
| 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.
| tonymet wrote:
| i guess engineering blogs have gone the way of recipes.
| Wuzado wrote:
| I absolutely love the writing style. Any other examples of blog
| posts written like that?
| teraflop wrote:
| Not quite the same style, but I enjoyed "Designing an
| Authentication System: a Dialogue in Four Scenes".
|
| https://web.mit.edu/kerberos/www/dialogue.html
| buzzwordninja wrote:
| The Phoenix Project is a book about agile project management.
| It's written in a similar style.
|
| https://www.goodreads.com/book/show/17255186-the-phoenix-pro...
| politician wrote:
| HN favorite 'Godel, Escher, and Bach' is written in this style.
| pcthrowaway wrote:
| Not a blog post, but https://howdns.works/ is a really
| brilliant (animated) webcomic explaining how DNS works through
| a story. Each panel has some title text as well.
| btown wrote:
| For more technical detail,
| https://linuxjournal.rubdos.be/ljarchive/LJ/298/12538.html goes
| into a TON more detail on this, including simplified code for the
| implementation of the which-socket-should-receive-this-packet
| algorithm.
|
| 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!
| toomanydoubts wrote:
| Thanks for synthesizing.
| sedatk wrote:
| Appreciated!
| vbezhenar wrote:
| How does ICMP routing work? I always wondered about that.
| There's no port in ICMP, how does OS understand which ping
| executable receives ICMP echo replies.
| toyg wrote:
| If I read this [0] correctly, there is still a hashmap of
| sorts.
|
| [0] https://flylib.com/books/en/3.475.1.74/1/
| zamadatix wrote:
| ICMP has an identifier field and a sequence number field,
| both exist to aid in matching requests with replies.
| account-5 wrote:
| I've no real knowledge of networking, I read this and have no
| idea what it's actually trying to teach. I say teach because I
| have read comments hear about it teaching but I can't actually
| speak to that. I am still as lost at the end as I was at the
| start, probably more so.
| dreamcompiler wrote:
| The article is aimed at low-level network programmers. I
| learned the subject from Stevens [0] which is quite old but is
| still one of the standard references.
|
| [0] https://www.amazon.com/UNIX-Network-Programming-Richard-
| Stev...
| thayne wrote:
| It talks about mapping a port (and ip address, and protocol) to a
| process, but on Linux (and I think other unixes as well) that
| isn't quite accurate. It maps to a file descriptor, and that file
| descriptor can potentially be share with other processes (for
| example by forking, or passing it over a unix domain socket). One
| common way this is used is to pass a socket file descriptor from
| the old process to the new process when restarting a service.
| xg15 wrote:
| This article has taught me the concept of "discovery fiction"
| and, I'm sorry to say so, but I already hate 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
| mikenew wrote:
| My first exposure to programming was a book my dad gave me
| called The Little Schemer, and I absolutely loved it. It's like
| discovery fiction without the fiction. It just asks a question
| and then immediately answers it; mostly composed of code with
| minimal explanation. It feels like a very natural progression
| of being exposed to something new, getting familiar with it,
| and starting to explore all the nuances.
|
| 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.
| [deleted]
| michael_nielsen wrote:
| As others have pointed out (e.g.:
| https://news.ycombinator.com/item?id=30324567 ), the style in
| this article is not what I had in mind when I coined the phrase
| "discovery fiction". It also has nothing to do with spaced
| repetition or having a "more natural flow".
| paulgb wrote:
| Sorry to drag you into this! I meant "inspired by" in the
| literal sense, not as a claim that it would fall under your
| definition. I mentioned so when I tweeted it, but not in the
| post itself
| https://twitter.com/paulgb/status/1492923557801869318?s=21
| michael_nielsen wrote:
| No worries. I'm glad you're experimenting!
|
| 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!
| sva_ wrote:
| It reminds me a bit of those recipe sites, where every recipe
| is preluded with a bunch of mostly irrelevant text. Low
| information-density.
| [deleted]
| burkaman wrote:
| I also found the style in this article kind of annoying and
| difficult to follow, but I think "discovery fiction" usually
| means something different. The two examples Michael Nielsen
| gives are https://michaelnielsen.org/ddi/how-the-bitcoin-
| protocol-actu... and https://michaelnielsen.org/ddi/why-bloom-
| filters-work-the-wa.... Another classic example is
| http://blog.sigfpe.com/2006/08/you-could-have-invented-
| monad....
|
| 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.
| theginger wrote:
| This example that explains kerberos is entirely dialog
| https://web.mit.edu/kerberos/www/dialogue.html Really helped
| me understand kerberos in a way other articles and technical
| documents had failed to.
| [deleted]
| macintux wrote:
| If you think this is forced, you should read one of "The Easy
| Way" math books, like https://www.thriftbooks.com/w/barrons-
| trigonometry-the-easy-...
|
| Fictional kingdom discovers Trigonometry out of necessity.
| marai2 wrote:
| Trigonometry The Easy Way, was brilliant! I wouldn't
| categorize it as forced in the manner of the OP. The book
| creates a fantasy backdrop to connect trigonometrical
| concepts in a fun way. I really enjoyed the book and it made
| trigonometry really stick in my brain!
| [deleted]
| renewiltord wrote:
| Haha entertaining. I rather like this style. I skipped till the
| first code and then the interludes were short. But I think I
| would have been annoyed if the first code block was not
| demarcated clearly so I could skip to it. The prelude was too
| long for me to read since I didn't know if there was going to
| be payoff.
| keithnz wrote:
| annoys me also, but I'm old and like things without a lot of
| fluff. I'm sure plenty of people enjoy this style.
| arittr wrote:
| agreed. it's not useful for me as a more "tech experienced"
| person and having taught many people just breaking into the
| industry i don't think it would help them much, either.
|
| 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.
| paulgb wrote:
| One thing I've learned about pedagogy is that it's a fool's
| errand to try to create material that works for everyone,
| because everyone learns differently. In fact, the meta story
| here is supposed to be about Liz and Tim having different
| styles of learning -- Liz learns by exploring off the beaten
| path, while Tim prefers to stick to the course content. Neither
| are wrong.
| systemvoltage wrote:
| I think "everyone learns differently" is an overblown claim
| and gets repeated ad-nauseum. It is an escape hatch to avoid
| deeper discussions of successful strategies, what it means to
| teach and learn. A sort of a deus-ex-machina of arguments.
| There are more universals about learning than differences. It
| effectively surrenders the failure of teaching to "Well, it
| must be because everyone learns differently". This way, we
| can never learn to teach or even debate about it.
|
| 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.
| openknot wrote:
| A relevant HN discussion exploring effective learning
| strategies was posted ~7 hours ago:
| https://news.ycombinator.com/item?id=30321632
|
| 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...
| modelviewpotato wrote:
| I've seen somewhere that "everyone learns differently" might
| not actually be true.
|
| I found this video from Veritasium that explains it:
| https://www.youtube.com/watch?v=rhgwIhB58PA
| rwoerz wrote:
| Exactly. This seems to be debunked: https://www.psychologic
| alscience.org/journals/pspi/PSPI_9_3....
| NineStarPoint wrote:
| This is saying that VARK method of describing learning
| styles is incorrect. This does not necessarily mean that
| there aren't differences in what are the best method's for
| different people learn. One issue with VARK is that it
| involves self-identification, as was the case in all
| studies mentioned in the video. There's no reason to assume
| that the way people prefer to learn is actually the best
| way for them to learn, it may be that people choose what
| seems right to them rather than what actually is. Another
| issue is, as is mentioned in the video, the domain you are
| studying also has an affect and multi-modal approaches are
| most useful. Whether learning styles exist or not, some
| information intrinsically is better presented as a diagram
| than a wall of text. And no matter if some people learn
| better in certain ways, it seem universally true that
| people learn better if information is presented to them in
| multiple forms instead of just one.
|
| 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.
| phkahler wrote:
| >> I've seen somewhere that "everyone learns differently"
| might not actually be true.
|
| 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.
| xg15 wrote:
| Ok, I didn't realize this aspect of the story, this is
| actually pretty cool, I agree.
|
| 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.
| SilasX wrote:
| I personally just hated the long-form-journalism style of
| "okay, at the start, you have to wade through a ton of
| irrelevant crap about the settings and the coil-bound notebooks
| they're using".
| ramesh31 wrote:
| >I personally just hated the long-form-journalism style of
| "okay, at the start, you have to wade through a ton of
| irrelevant crap about the settings and the coil-bound
| notebooks they're using".
|
| 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.
| progbits wrote:
| I'm convinced lots of sites do this just to push out the
| actual content below the "please login / buy subscription to
| continue reading" point, or if it is a free article at least
| make you scroll through as many inline ads as they can.
| ajkjk wrote:
| For recipes, yeah, but this sounds like just the writer
| taking artistic license to write how they want.
|
| I liked it, for what it's worth.
| [deleted]
| brimstedt wrote:
| I thought the story was pretty good, it's a nice change from
| the all-facts texts I usually read.
|
| 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.
| paradite wrote:
| I guess you wouldn't like _Sophie 's World_ either.
| rsync wrote:
| ... and _run away screaming_ from _Fall_ by Neal Stephenson
| ...
| xg15 wrote:
| It came to my mind after writing that post :)
|
| 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.
| [deleted]
| [deleted]
| macintux wrote:
| Paul, there's a typo in one code snippet where you show 128.0.0.3
| instead of 127.0.0.3.
|
| Great article, enjoyed it.
| paulgb wrote:
| Fixed, thank you! (might take a bit to hit the CDN)
| sodality2 wrote:
| I absolutely love this writing style. Great article, thanks!
| jll29 wrote:
| Well done - thanks. A good dialogue, reminds me a bit of those
| written by Plato (okay, apart from the difference in topic); I
| wish I had more inquisitive students like Liz.
| imwillofficial wrote:
| I applaud the author's attempt to dig into an important and
| fundamental question often overlooked.
|
| But this was such obtuse writing that was painful to read.
|
| I recommend a less clunky narrative based format.
| indigodaddy wrote:
| Man, the author was listening closely to that conversation!
| qwertox wrote:
| For me SO_REUSEPORT was only a solution to be able to immediately
| reuse a port when a process crashed in some odd way and the OS
| was not releasing the port immediately.
|
| 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.
| y04nn wrote:
| There is data piping needed between the main thread and
| workers, each new connection is handled to a worker as a socket
| descriptor, like a pointer.
| parentheses wrote:
| Great article!
|
| The storytelling style, however is very difficult to skim. It
| really requires reading dialogues and actions.
| trulyme wrote:
| It is however a joy to read, at least for me. Kudos to the
| author!
| aunty_helen wrote:
| If you're looking to skim for answers, this probably isn't the
| resource you would come across.
|
| However, it's a Sunday afternoon, raining and there's thunder
| in the background. It's the perfect style to relax and enjoy.
| cryptojanne wrote:
| Horrible way to write, so many unnessecary words. Not for me.
| [deleted]
| bravetraveler wrote:
| I agree, but I know some people who like this style.
|
| 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.
| toyg wrote:
| The style can work. In this case it largely doesn't, mostly
| because the writer insists in trying to be cute about "Tim".
| Tim is a sockpuppet for the author, like Socrates in Plato's
| works. After the first couple of paragraphs, there is no
| point pretending he is anything but that. Trying to flesh him
| out, over and over through the text, is a waste of everyone's
| time.
| dang wrote:
| " _Please don 't post shallow dismissals, especially of other
| people's work. A good critical comment teaches us something._"
|
| https://news.ycombinator.com/newsguidelines.html
| elcapitan wrote:
| This is horrible to read. I gave up after the first screen page.
| When I'm trying to extract knowledge from a post or an article, I
| don't want it padded with useless prose that I need to skip when
| parsing the text. Like an invasion of this fluff style of "long
| read" that has become fashionable in what used to be journalism.
| [deleted]
| jsiaajdsdaa wrote:
| You would love recipe blogs then!
| accrual wrote:
| Interestingly, the life stories surrounding recipes may be a
| form of copyright protection.
|
| > 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...
| dec0dedab0de wrote:
| That was fun, but more about Linux than ports in general. I was
| expecting something more along the lines of a computer checks the
| port of every incoming packet and if it matches something it is
| expecting it does something. Though this was much more
| interesting, and now I'm curious about even more specifics of how
| Linux handles this.
| btown wrote:
| See my top-level comment:
| https://news.ycombinator.com/item?id=30324520
| inopinatus wrote:
| 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!
|
| -- Gene Ziegler, _" A Grandchild's Guide to Using Grandpa's
| Computer"_ (1994)
| andrewstuart wrote:
| The other interesting thing about ports is when you release it,
| it's not available again for some period of time like 60? 30?
| seconds.
| criticaltinker wrote:
| Had to read quite a bit before getting to the core insight:
|
| > "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."
| NoWizards wrote:
| thanks for this summary (the lecture was pretty boring to me).
| As i understood it, the article explains what happens when you
| listen to same or similar combinations of a port-ip-protocol-
| whatever... but i didn't learn what does it mean to "listen" on
| a port. how does two programs communicate by this way?
| thaumasiotes wrote:
| The port number is one field in a TCP or UDP packet. When you
| listen, you register with the operating system (or whatever
| controls the network card, I guess) saying that you want a
| particular port. When a packet comes in (on the network
| card), it will be routed to you (on your socket) if it's
| addressed to you (by including a port number you're
| registered for).
|
| 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".
| Dylan16807 wrote:
| "and an IP version" is more of a matter of interpretation
| though. I'm pretty sure you can model that behavior in terms of
| binding to an IPv4 address and binding to its _associated_ IPv6
| address. Rather than binding to the _same_ IP with different IP
| versions.
|
| 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.
| pdimitar wrote:
| I've read the whole thing patiently even though I am not sold on
| the format of such stories -- but it was still informative.
|
| 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?
| badwriter32 wrote:
| This article had a fun, enjoyable writing style, thanks!
| cgreerrun wrote:
| With a little formatting to make it feel like a fiction book, the
| writing style works much better for me:
| https://imgur.com/a/5R3x2BL
|
| 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;
| }
| userbinator wrote:
| It seems this style of writing is quite divisive, but those who
| liked it may also enjoy The Manga Guide series:
| https://news.ycombinator.com/item?id=30120927
|
| 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.
| [deleted]
| Closi wrote:
| I think this style of writing can work - but it works best if
| the story is something other than two people just talking about
| 'how do you think this thing works?'.
|
| 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!).
| reilly3000 wrote:
| I think that the process of discovery is engaging, and far
| more relatable than a man page. Maybe the prose went a little
| further than it needed to, or as you suggest not far enough.
| I'm just saying that the mechanism of storytelling exploits
| some attributes of our evolutionary biology that make
| learning a concept more relatable and memorable.
| dghughes wrote:
| I wonder if it's like recipes where the author writes in an
| elaborate style to prevent theft of their material. "I
| discovered this pizza recipe when I was hitchhiking through
| Naples after the death of my father. I was trying to find
| myself...". Instead of just typing out the recipe.
| stevage wrote:
| I really liked it. Especially the implied message that the
| reader could also figure this out by a similar process of
| investigation.
| bryanrasmussen wrote:
| and here I always thought it was a nautical term from the days of
| Francis Drake when most sailors were also spies for their
| respective countries.
|
| Kit Marlowe was listening on a port down by his favorite tavern,
| planning on skipping out on bail, when he was knifed to death.
| piyh wrote:
| I love articles like this where it goes deeper into a fundamental
| idea that I've only interacted with on a "do what I need done"
| level.
| theamk wrote:
| Fundamental? I see it the other way -- this is an illustration
| of how neat, fundamental concept ("When you bind to a port, it
| puts a pointer to your socket in that table.") is actually full
| of random hacks and ad-hoc changes. The linux kernel is full of
| random logic like this, and this article could be continued
| (there are at least network namespaces and sys.net options to
| consider).
|
| 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.
| oblio wrote:
| We can't really blame Linux for this, this is a networking
| protocols problem.
|
| It's their stack of hacks.
| ratorx wrote:
| Well only sort of. As far as I understand, nothing about
| TCP means that ports can be reused, or that 0.0.0.0 has
| special meaning, or that processes can't listen on the same
| port, or IPv4 to IPv6 delivery etc. These are all operating
| system design choices, some of which stem from the sockets
| API.
|
| I'm pretty sure you could design a spec-compliant
| alternative which didn't do any of these things, if you
| really wanted to.
| wyager wrote:
| TCP and UDP don't really dictate any of this behavior. Most
| of these hacks are the result of design choices in Linux
| and the socket API - abstractions on top of TCP/UDP that
| aren't the only option.
|
| 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.
| freetime2 wrote:
| This article really left me wanting to learn more... about the
| budding relationship between Tim and Liz.
|
| Maybe in the next chapter Tim can confess his feelings for Liz
| while they learn together about Unix Domain sockets?
| [deleted]
| electrondood wrote:
| CMD-F "so" to find the TLDR
| squarefoot wrote:
| I made extensive use of the SO_REUSEPORT flag a couple decades
| back to build agents that on the same machine would have their
| own UDP socket which received data from a local piece of
| software. Basically, by using that flag each socket received a
| copy of the buffer, so that each agent could act upon the
| contents ("is it for me? - if yes then read this field and act
| accordingly, otherwise ignore"). Very handy, despite all
| limitations of UDP. It allowed me to keep the code very tight and
| specific for every agent, although network buffer structures were
| all in common so upgrading the protocol to all agents was easy.
| With some adaptations, it worked both on Windows's POSIX stack
| and Unix.
| robotresearcher wrote:
| My recollection of SO_REUSEPORT behavior is that it will
| deliver a datagram to one listener, rather than all of them.
| The kernel will distribute datagrams fairly between listeners
| over time, so none are starved. This makes it super easy to
| share load over multiple servers, but doesn't get the same
| datagram to multiple listeners.
|
| This seems to confirm: https://lwn.net/Articles/542629/
|
| Maybe the exact behavior varies by platform. I've never used it
| on Windows.
| squarefoot wrote:
| > Maybe the exact behavior varies by platform.
|
| 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.
| haneefmubarak wrote:
| I haven't confirmed the behavior on BSD manually, but based
| on skimming https://stackoverflow.com/a/14388707/2334407 and
| https://www.freebsd.org/cgi/man.cgi?query=setsockopt&sektion.
| .. , I'm inclined to believe their implicit claim that the
| original behavior of SO_REUSEPORT is to duplicate everything
| to each listener. In fact, it looks like Linux copied the
| behavior of SO_REUSEPORT_LB and called it SO_REUSEPORT.
|
| Ahhh, the joys of "portability"...
| thaumasiotes wrote:
| The freebsd page doesn't claim that it delivers everything
| to every listener. It says that's possible _if_ multicast
| or broadcast is configured. That won 't happen by default.
|
| > This option permits multiple instances of a program to
| each receive UDP/IP multicast or broadcast datagrams
| destined for the bound port.
| ww520 wrote:
| This sounds very handy for broadcast within a box type of
| applications.
| RyanHamilton wrote:
| Are you sure? I didn't think SO_REUSEPORT was that old. ~2013
| on linux.
| timc3 wrote:
| Still doesn't explain it. I guess it would take a book to get
| through exactly what is happening.
| alexk307 wrote:
| Right!? This just shows by example the basics of calling the
| socket syscalls via Python. I still do not know how these
| syscalls work or what it really means to be listening to on a
| port.
___________________________________________________________________
(page generated 2022-02-13 23:00 UTC)