Live data from Hacker News

Network protocols for anyone who knows a programming language

destroyallsoftware.com

21–30 of 72 posts

Re: Network protocols for anyone who knows a programming language

#21

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 all the good software developers I know are also good writers. That if you can write an essay, you can also code. The problem is that most people are terrible writers, programmers included.

I will admit that writing is harder than programming. Because people are far more interesting, complicated, nuanced than computers.

Reading someone else's code is the closest thing we have to mind reading. More so than prose. IMHO.

Miscommunication and ambiguity is the norm. We all just have to accept that and keep trying.

Re: Network protocols for anyone who knows a programming language

#22
post #9
post #3

One interesting note re: 8b/10b encoding. The motivation in the article is accurate, but not the whole story (never is, in the analog world). Nowadays, 8b/10b (or more realistically 128b/130b) is critical to enable clock recovery by making sure the signal transitions frequently enough. > Computers can't count past 1 Reminds me of this excellent quote: "Every idiot can count to one" - Bob Widlar

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

Re: Network protocols for anyone who knows a programming language

#24

Earlier quoted context omitted.

Agree, and love that guys domain name.

I love it too. Sadly, not to long ago he considered changing it because it makes their materials a hard sell to enterprises.

Some people have a "normal" site with "normal" pricing and an "enterprise" site with different formatting, pricing, etc (for example it could have a search box, even if all the searching is just a google search anyway).

The corporate pricing could include a commitment to update some percentage of docs within 12 months of a relevant RFC being published or whatever.

Keeps purchasing happy, is a way for folks in the enterprise to get their employer to fund some resource and still gets it to mostly remain a labor of love.

I attend a conference that works that way. Essentially there are two conferences at the same time, with identical badges (no conference name on the badge itself), one of which costs about $800 and one of which costs about $3000 IIRC, if you buy all the special upgrades. Any company that pays the for the "corporate" conference gets listed as a sponsor as well :-).

Re: Network protocols for anyone who knows a programming language

#25

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…

That does, thanks for sharing.

Re: Network protocols for anyone who knows a programming language

#26
The slow start mentioned in the transmission control section has an interesting history.

Back when most internet packets were single characters representing keystrokes over something like Telnet, an algorithm was invented to wait a moment before sending ACKs in order to possobily piggy back out on the next data packet.

This ended up interplaying with TCP slow start and adaptaive congestion control for years and was only resolved in the early 2000s if if I recall correctly.

The inventor of that algorithm posts here frequently if he wants to comment on my post about this again. :)

Re: Network protocols for anyone who knows a programming language

#28

I love the ending... just goes to show that anything you build may be around for years longer than you expect.

That's a romantic way to look at technical debt! :-P

It's not technical debt, it's more like technical ex-girlfriends.

Re: Network protocols for anyone who knows a programming language

#29
post #26

The slow start mentioned in the transmission control section has an interesting history. Back when most internet packets were single characters representing keystrokes over something like Telnet, an algorithm was invented to wait a moment before sending ACKs in order to possobily piggy back out on the next data packet. This ended up interplaying with TCP slow start and adaptaive congestion control for years and was o…

https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm

Re: Network protocols for anyone who knows a programming language

#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 recommend to any software developer. Available for free here - https://hpbn.co

Post reply on HN