Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Network protocols for anyone who knows a programming language

destroyallsoftware.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Network protocols for anyone who knows a programming language

#61

Post by canada_dry »

jonah-archive wrote: post #57
canada_dry wrote: post #37

Earlier quoted context omitted.

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.

Yup... agreed.

I just wish someone would come up with an associated easy-to-digest guide-for-dummies for a few different real world scenarios.

Re: Network protocols for anyone who knows a programming language

#62

Post by benjamincburns »

Wowfunhappy wrote: post #58

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.

Thanks to cumulative windowing, it does have a dropped packet signal: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#...

Re: Network protocols for anyone who knows a programming language

#63

Post by kevintb »

nindalf wrote: 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…

Interesting, I think that textbook is one of the best I’ve read on networking. It gave me the foundational knowledge on approaching networks.

Re: Network protocols for anyone who knows a programming language

#65

Post by lpmay »

I love this article, but I just can't help but pick at this nit I have with the "charging the capacitors" part. I'm not intimately familiar with Ethernet specifically, but I am an electrical engineer. Since the voltage on a capacitor is directly related to the charge it has stored ( scaled by a factor called it's capacitance :-) ), holding the capacitors at any fixed voltage for any length of time does not change how "charged up" it is at all. I would believe that there is a "line balancing" goal to the transmissions, but I'd be willing to bet it is to avoid driving the isolation transformers into saturation, and has nothing to do with low pass filter capacitors...

Re: Network protocols for anyone who knows a programming language

#66

Post by 9dev »

The network stack is one of the most beautiful inventions in the whole tech space to me. All the involved layers nest so neatly, allowing to switch out any of them as necessary and simply unwrap at the receiving end. After years of witnessing programmers inventing new dependency injection schemes, I still can't switch from MySQL to Postgres by simply swapping the driver. Compare that to transmitting TCP over avian carriers ;)

Re: Network protocols for anyone who knows a programming language

#67

Post by mhandley »

Wowfunhappy wrote: post #58

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.

How would the receiver know a packet was lost? If only one packet was sent, it cannot know, so you always need a retransmit timer at the sender as the ultimate backstop for reliability. Any other trigger of retransmissions is an optimization.

Now, why not a NACK rather than relying on duplicate ACKs? First, the NACK can get lost, so you'd probably want to trigger fast retransmit off of duplicate ACKs anyway for efficiency. But when should the receiver send a NACK? Given that packets can be reordered, likely you want to wait for a few subsequent packets to arrive before you send the NACK. In that time, you've been acking the arriving packets. So your NACK will arrive just after the sender has concluded the packet was lost from the arriving duplicate ACKs. At this point the NACK is serving no purpose.

Even if you wanted to change TCP and assume no packets were reordered, so send a NACK as soon as the packet after the missing one arrives, you'd still be ACKing the arriving packet (which due to TCP's cumulative ACK appears to the sender as a duplicate ACK). The sender could just as well retransmit after one duplicate ACK and get he same behaviour. In the end, sending a NACK doesn't really add anything.

Re: Network protocols for anyone who knows a programming language

#68

Post by kingosticks »

My nitpick would be the example Cisco router:

> As an example, Cisco ASR 9922 routers have a maximum capacity of 160 terabits per second. Assuming full 1,500 byte packets (12,000 bits), that's 13,333,333,333 packets per second in a single 19 inch rack!

The ASR 9922 is 20 slots of 3.2Tbps per slot. That's a 64Tbps chassis so that's 5,333,333,333 packets per second in a single 19 inch rack. Cisco's 160Tbps number is their hypothetical multi-chasis setup. Which is fun to market but non-sensical to build/purchase.

Re: Network protocols for anyone who knows a programming language

#69

Post by tastroder »

EnFinlay wrote: post #35
nindalf wrote: 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…

It seems every intro to networking goes into the headers of each layer's most common protocol.

That's a good thing imho, at least if accompanied by something that gives you the more practical perspective on layers 4 and above as well (which is probably where many curricula fail). Of course it's more interesting to do fun stuff with fancy JSON APIs or create a funky WiFi mesh, it's even likely to be more relevant to most people's future job since not that many people focus on networking. But it's a foundation that can be interesting and help many optimizations down the road, it simply is not academias primary and exclusive focus to prepare students for some job. Just like many people take other stuff from CS programs that you simply don't learn in a 3 month Python course, undertanding of networking protocols is something that _may_ help and give you an advantage for future problem solving. It might even be thought inspiring enough for you to focus on in the first place.

Re: Network protocols for anyone who knows a programming language

#70

Post by bogomipz »

dublin wrote: post #55
bogomipz wrote: post #15

Earlier quoted context omitted.

>"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…

Interesting. I knew someone that worked for an ISP in 90's who had an odd SGI workstation amongst their standard SUN boxes for hosting customer sites. The SGI box was regarded to be faster than the newer SUN boxes. Eventually all customers were migrated off of the SGI box except one customer who refused and threatened to sue. I wonder if the reason for the performance gains of the SGI were the same as yours.

I believe 802.11n reduced the interframe gap down to a two microseconds for transmissions to the same receiver.

Post reply on HN