51–60 of 66 posts
What is the general lesson we should learn from this? Postel's law aka robustness principle [1] can easily lead into accumulating complexity when implementations adapt to the bugs in other implementations. How could protocol designers mitigate this problem beforehand? [1]: https://en.wikipedia.org/wiki/Robustness_principle
Earlier quoted context omitted.
Great story with the added bonus of showing me the GNU Units command. What a fantastic program, no more Googling when I need to convert stuff.
Indeed, I just checked OSX - sadly, units doesn't know about millilightseconds ("586 units, 56 prefixes").
Earlier quoted context omitted.
Indeed, I just checked OSX - sadly, units doesn't know about millilightseconds ("586 units, 56 prefixes").
"milli lightsecond" should do it.
(I learned this by reading the /usr/share/misc/units.lib file and finding the lightyear definition: "c-yr")
Earlier quoted context omitted.
"milli lightsecond" should do it.
"milli lightsecond" doesn't work on OSX unfortunately (under 10.6 at least). One value which does work is "3 c-millisecond". (I learned this by reading the /usr/share/misc/units.lib file and finding the lightyear definition: "c-yr")
This reminded me of the best TCP timeout story I've ever heard, the case of the 500-mile email: http://www.ibiblio.org/harris/500milemail.html
Great story with the added bonus of showing me the GNU Units command. What a fantastic program, no more Googling when I need to convert stuff.
This reminded me of the best TCP timeout story I've ever heard, the case of the 500-mile email: http://www.ibiblio.org/harris/500milemail.html
Earlier quoted context omitted.
I don't think it was an issue with the timeout. The other side simply could not handle retransmitted SYN. At all. The 500ms comes up only because that happened to be their RTT. If they used 1 second, this host would work, but another one using the same stack but with 1 second delay would continue to fail. It's not about the other host not having an ideal implementation, or about testing ideal cases. The other host ha…
I worked for many years with the locations on the remote islands with the high RTT. You wouldn't believe how much software of the biggest industry players failed to work under that circumstances. My favorite case was when one company first claimed "OK on another side is probably the device from the competition." It was their device on another side too. They "debugged" the case for a bigger part of the year and the ca…
There is no evidence that he expected everyone else to be perfect. This is simply a debugging story about a case where he found an unexpected problem with an interesting cause. You don't need to make it an opportunity for treating him like he was stupid for having a bug.
edit: and in fact, you say in your response, "You wouldn't believe how much software of the biggest industry players failed to work under that circumstances." In other words: "You wouldn't believe X! But if you're surprised by X, I will scoff and act like you're a clueless noob for not anticipating X."
Earlier quoted context omitted.
I worked for many years with the locations on the remote islands with the high RTT. You wouldn't believe how much software of the biggest industry players failed to work under that circumstances. My favorite case was when one company first claimed "OK on another side is probably the device from the competition." It was their device on another side too. They "debugged" the case for a bigger part of the year and the ca…
> I concur that the TCP is damn hard. It's just that you can't expect that "everybody else" is perfect. There is no evidence that he expected everyone else to be perfect. This is simply a debugging story about a case where he found an unexpected problem with an interesting cause. You don't need to make it an opportunity for treating him like he was stupid for having a bug. edit: and in fact, you say in your response,…
So everything revolves really around the less common timeout times all the time, the wish to use them everywhere, the discovery that they don't work everywhere and the resulting feeling "from my point of view this is a particularly annoying bug." Which is exactly what I commented to from the start. True, the sentences in the original aren't dominating the whole text, so the less attentive reader (or readers in this case) can miss that.
There are two different approaches to write the article:
1) I will show you that the other side is wrong (spending 95% of time on that). It is annoying because our clever new code doesn't work with it whereas old less clever does.
2) We developed a clever new TCP code. We thought we're clever. But some nodes on the internet are less clever. I'll show you an example.
I claim that the approach 1) implies your belief that it's more important to you is that you're "right" than what actually works.