Live data from Hacker News

Network protocols for anyone who knows a programming language

destroyallsoftware.com

51–60 of 72 posts

Re: Network protocols for anyone who knows a programming language

#51

With the current state of generally terrible technical writing and my ever decreasing attention span it's bloody refreshing to read a concise and well written explanation of a highly technical subject! I'll definitely have to check out the rest of their 'compendium': https://www.destroyallsoftware.com/compendium

"current state of generally terrible technical writing" I've served the technical writing role a few times. If it (your product) is hard to describe, you probably did it wrong. At the very least, keep trying until things make sense. Better mental models, metaphors, workflows, whatever. I was once asked (by a school principle, former writing teacher) why software developers are such terrible writers. I replied that al…

Not only that, the very idea of clear, literate explanations is really a core part of the entire Internet ethos, heavily influenced by UNIX. (Read http://theody.net/elements.html - you'll be glad you did...)

This was revolutionary back in the days when most protocol specs were proprietary and designed to protect the priesthood (usually of a particular vendor)rather than facilitate interoperability. It's hard to imagine now, but one of the big reasons TCP/IP won was that it actually encouraged interoperability and interworkability. (Jan Stefferud drew a distinction between those two terms in this context...)

Re: Network protocols for anyone who knows a programming language

#52
post #9

Earlier quoted context omitted.

Yeah, that section is a little ropey; the real way to think of high-speed networking systems is not that they send levels but that they send edges . Levels can drift around all over the place, and in a fast system the level at one end is not the same as the level at the other. This line of thinking makes clearer what signal reflections are and why they are a problem, and what the role of eye diagrams is.

The Art of Electronics[1] has a fantastic section on differential signaling and common mode voltage. That book is a treasure even today despite being published initially in 1980. [1] https://en.wikipedia.org/wiki/The_Art_of_Electronics

Oddly, nothing has changed in the way God made the universe in the intervening years. Some things are timeless.

Re: Network protocols for anyone who knows a programming language

#53
post #12

Earlier quoted context omitted.

Is it also to allow other nodes on the network to communicate, especially if they're on the same collision domain?

No. Wired ethernet hasn't used collison-based protocols in a long time. It's point-to-point now, not shared.

Actually, even though most connections are switched point-to-point these days, any properly functioning implementation (definitely up through 100Mbps) must still implement CSMA/CD. It's required for proper functioning of Ethernet hubs and some bridges!

Re: Network protocols for anyone who knows a programming language

#54

Earlier quoted context omitted.

What do you see as an issue in technical writing, if anything past not concise or well written?

I suppose it boils down to why the Feynman lectures are generally considered a gold standard in technical presentations. His explanations focus on the most important bits (which he has skillfully prioritized based on his expert knowledge) and avoid highly domain specific nomenclature i.e. he gives a thorough-yet-concise explanation in a way that a reasonably intelligent lay person can understand. Does that make sense…

The Feynman lectures are also not useful to learn physics from, so you may want to avoid that as a standard.

Re: Network protocols for anyone who knows a programming language

#55

Earlier quoted context omitted.

Kind of! They allow systems with slightly different clock rates to adjust. A system sending data nominally at 10 Gb/s can actually run slightly faster to a system running slightly slower b/c their timing bases (crystals) oscillate at slight different frequencies.

>"They allow systems with slightly different clock rates to adjust." Adjust to what? Ethernet is not synchronous its asynchronous. There is no shared clock. The interframe gap goes back to the days of CSMA/CD. The interframe gap was the period during which end stations would contend for the shared medium. Without this an end station could continuously stream and monopolize the network.

Back when I worked at Chevron in the early 90s, I noticed that new SGI workstations were way faster NFS servers than anything else, even the Suns. It took me a bit in those days (Ethernet network analyzers were over $50K then, so hard to borrow even in a big, rich company) to figure out why:

It took 6 Ethernet frames to send a single 8K NFS block, and regaining the carrier could be pretty time-consuming if there was other traffic. So SGI implemented a really elegant cheat that technically violated the Ethernet standards, but dramatically improved performance for the entire network, and especially their NFS servers: They simply never let anyone else get a chance to talk until they'd sent the entire block, "hogging" the carrier by going straight from the last bit of the previous frame to the preamble of the next one. It was a very clever way of more-or-less getting jumbo frames years before they became part of the standard!

Re: Network protocols for anyone who knows a programming language

#56
post #49
post #47

Earlier quoted context omitted.

This is pretty frequently debated. You can find textbooks that start at L1 and work up the stack, and others that start at L7 and go down.

Starting at Layer 7 is a fundamental mistake, because it perpetuates the execrable and obsolete OSI 7-layer model. Since IP protocols DO NOT map cleanly to the OSI model, trying to shoehorn IP into it causes more misunderstanding than anything else I've seen in networking. Seriously - IGNORE the 7-layer model if you want to understand real-world protocols and their design, especially anything IP-flavored. (BTW, David…

> Does anyone actually use any OSI protocols anymore?

OK, here's my conspiracy theory:

At a certain point, the OSI people knew they were losing. However, they were the people in charge of the big institutions, so they made a push to ensure that history books would be re-written such that, well, of course we all use the OSI Model, of course the Internet people implemented OSI, there was never a debate, don't be silly! Eastasia and Oceania have always been at peace, and that's why, here in Airstrip One, you need seven layers to describe how anything which moves over a network works!

... and the fact the OSI Model was attached to actual protocols is silently forgotten, as is the fact the ARPANet/Internet people were mildly opposed to "layers" as a conceptual model and never took the OSI Seven-Layer Model as a design document!

Re: Network protocols for anyone who knows a programming language

#57
post #30

I took a networking course in college and I didn't learn much, if anything. We used textbooks like Kurose and Ross that went deep into details like the header format of each packet of each layer. Ultimately, these were useless details that had no place in a textbook. It made me hate the subject. I eventually learned the subject properly through High Performance Browser Networking. This is the one book I would recomme…

Can anyone recommend an excellent resource on how IPTABLES work? One with diagrams and real world examples?

I cannot recommend this specific diagram highly enough: https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilte...

I've easily had a dozen times where I was able to resolve a complex problem or figure out how to do the thing I wanted to do through examination of this flowchart.

Re: Network protocols for anyone who knows a programming language

#59

Why doesn't TCP have an "I lost a packet" message? Is it just that no one thought of it until too late? Hacking around the problem by sending multiple ACK's sounds inefficient.

Don't know about TCP. In the 90s, I hand implemented a data/file transfer protocol over trunking radio - a very data unfriendly medium with pretty bad loss rates.

I thought about "I lost a packet" message, but if it got lost in transmission, sender would never know to resend the packet. Instead, the sender had the responsibility of keeping track of which packets it received an ACK for. If it didn't receive the ACK, it would resend the packet within a certain interval and wait for another ACK.

Re: Network protocols for anyone who knows a programming language

#60

Earlier quoted context omitted.

Same with my college networking class. The professor talked a lot but we didn't do much besides look at HTTP requests in Wireshark. The most practical thing I had to do with networking cane up in a job interview where I paired with someone to work on some low later stuff.

They didn't have you setting up networks with real hardware in a LAB ? Not sure that starting with http requests is a good idea you need to start at layer 1 and work up.

While we learnt from Layer 1, all the setup was in software so we didn't get any hardware.

I think the idea is that we could examine Wireshark frames for the relevant layers.

Post reply on HN