In highschool I carried TCP Illustrated around with me like a bible. I cherished that book. Knowledge of networks would eventually be incredibly useful throughout my career.
How a little bit of TCP knowledge is essential
21–30 of 44 posts
Re: How a little bit of TCP knowledge is essential
#22This is my proposed solution to this kind of problem: Sockets should have a flushHint() API call: http://www.forwardscattering.org/post/3
Re: How a little bit of TCP knowledge is essential
#23This is a general problem of leaky abstractions. If you're a top-down thinker, you're going to have a bad time some day and have a hard time figuring it out. OTOH bottom up thinkers take much longer to become productive in an environment with novel abstractions. Swings and roundabouts. Top down is probably better in a startup context - it's more conducive to broad and shallow generalists. Bottom up is great when you…
Careless piling of layers atop layers is the main reason why everything is slow when computers are crazy fast. Every moderately complex piece of software is so inefficient that it is better not to think about it or else you become paralyzed in horror ;)
Usually something is done to mitigate these inefficiencies only when they become egregious. And that is when even basic knowledge of the inner workings of underlying layers really pays off (see also: mechanical sympathy).
Re: How a little bit of TCP knowledge is essential
#24Can wireshark/riverbed (application perf tests) profiling help to solve these kind of problems?
Wireshark can show you the delay but it won't tell why it's there. You might assume it's some quirk of your application.. Most people don't consider the kernel/network libraries and drivers.. Those are all black magic
Re: How a little bit of TCP knowledge is essential
#25This is a general problem of leaky abstractions. If you're a top-down thinker, you're going to have a bad time some day and have a hard time figuring it out. OTOH bottom up thinkers take much longer to become productive in an environment with novel abstractions. Swings and roundabouts. Top down is probably better in a startup context - it's more conducive to broad and shallow generalists. Bottom up is great when you…
Careless piling of layers atop layers is the main reason why everything is slow when computers are crazy fast. Every moderately complex piece of software is so inefficient that it is better not to think about it or else you become paralyzed in horror ;) Usually something is done to mitigate these inefficiencies only when they become egregious. And that is when even basic knowledge of the inner workings of underlying…
I am currently writing a client to a synchronized application system, and you only really notice how it’s layers upon layers when you write custom functions to serialize/deserialize primitive data types to a raw socket, and then on the next layer already can just abstract and write objects first to a HashMap, and then use the HashMap serializer for sending the actual object. And then you go yet another layer higher and use reflection to automatically sync method calls.
It’s really crazy to think about it.
Re: How a little bit of TCP knowledge is essential
#26That still irks me. The real problem is not tinygram prevention. It's ACK delays, and that stupid fixed timer. They both went into TCP around the same time, but independently. I did tinygram prevention (the Nagle algorithm) and Berkeley did delayed ACKs, both in the early 1980s. The combination of the two is awful. Unfortunately by the time I found about delayed ACKs, I had changed jobs, was out of networking, and do…
One thing that confuses me is -- are ACK delays part of the default TCP implementation on Linux? I originally assumed this was some kind of edge case / unusual behavior.
[deleted]
Re: How a little bit of TCP knowledge is essential
#27That still irks me. The real problem is not tinygram prevention. It's ACK delays, and that stupid fixed timer. They both went into TCP around the same time, but independently. I did tinygram prevention (the Nagle algorithm) and Berkeley did delayed ACKs, both in the early 1980s. The combination of the two is awful. Unfortunately by the time I found about delayed ACKs, I had changed jobs, was out of networking, and do…
One thing that confuses me is -- are ACK delays part of the default TCP implementation on Linux? I originally assumed this was some kind of edge case / unusual behavior.
So it would appear, according to the man pages: http://linux.die.net/man/7/tcp
In quickack mode, acks are sent immediately, rather than delayed if needed in accordance to normal TCP operation.
So "normal TCP operation" is to delay ACKs "if needed". Not sure if "needed" is the right word to use, but whatever.
Looks like RHEL has a system-wide fix: https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
Re: How a little bit of TCP knowledge is essential
#28That still irks me. The real problem is not tinygram prevention. It's ACK delays, and that stupid fixed timer. They both went into TCP around the same time, but independently. I did tinygram prevention (the Nagle algorithm) and Berkeley did delayed ACKs, both in the early 1980s. The combination of the two is awful. Unfortunately by the time I found about delayed ACKs, I had changed jobs, was out of networking, and do…
How did you end up switching from networking to animating falling bodies? What are you doing these days?
I wish you hadn't signed your comment, so we could have had the "I am John Nagle" moment when someone inevitably tried to pedantically correct you. :)
Re: How a little bit of TCP knowledge is essential
#29This is my proposed solution to this kind of problem: Sockets should have a flushHint() API call: http://www.forwardscattering.org/post/3
Look up the history of the PUSH bit in TCP.
Re: How a little bit of TCP knowledge is essential
#30That still irks me. The real problem is not tinygram prevention. It's ACK delays, and that stupid fixed timer. They both went into TCP around the same time, but independently. I did tinygram prevention (the Nagle algorithm) and Berkeley did delayed ACKs, both in the early 1980s. The combination of the two is awful. Unfortunately by the time I found about delayed ACKs, I had changed jobs, was out of networking, and do…
How did you end up switching from networking to animating falling bodies? What are you doing these days? I wish you hadn't signed your comment, so we could have had the "I am John Nagle" moment when someone inevitably tried to pedantically correct you. :)
"How did you end up switching from networking to animating falling bodies? What are you doing these days?"
Ford Aerospace got out of networking, then computer science, then closed the Palo Alto facility. I was out long before then.
What am I doing now? Robotics, again. Most recent GitHub commit: [1]