11–20 of 66 posts
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
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
Good read. I guess now we'd be interested in hearing your 2nd best TCP timeout story.
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.
Good read. I guess now we'd be interested in hearing your 2nd best TCP timeout story.
I realise you're trying to be facetious, but probably this one: http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-so...
Is there a history of these compatibility workarounds being the source of security bugs(e.g. DoS)?
I've to confess I've quite limited knowledge with TCP/IP stack internals, e.g. the way stack extensions work et cetera. Does anyone know of any available online visual materials/tutorials? I'm particularly searching for tools capable of recording and replaying TCP/IP stack packets with visual representation, references to RFCs and specifications.
https://www.cs.purdue.edu/homes/comer/netbooks.html
Richard Steven's "TCP/IP Illustrated" books are the original works, Unix network programming at its finest. More advanced than Comer's book, and much more applicable. Get used, older editions if cheaper, you will be fine.
Earlier quoted context omitted.
Good read. I guess now we'd be interested in hearing your 2nd best TCP timeout story.
I realise you're trying to be facetious, but probably this one: http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-so...
I know I'm stretching my luck, but since those were great reads - do you have a 3rd best TCP timeout story? :)
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.
The author uses the customized settings for his TCP stack and then laments that some nodes on the internet which aren't under his control depend on more common settings. Honestly I don't see why he could have expected any different outcome.
The other node doesn't depend on the settings, it depends on not receiving a duplicate SYN.
"Our TCP implementation has a variable base SYN retransmit timout, and in this case it was roughly 500ms. So most of the time the page load would fail with our TCP stack, but succeed with an off the shelf one that had a SYN retransmit timeout of 1 second."
If his timeout were 1 second, his connection with the other node would work. It's his own choice to insist on "variable base SYN retransmit timeout" even with the nodes which weren't tested with such a setup. He also says:
"The options are either to tell a customer that some traffic won't work (which is normally unacceptable, even if the root cause is undeniably on the other end), or to water down a useful feature a little bit to at least fail no more often than the "competition" does."
Meaning, the way they use that less common setting is "all or nothing": either all clients or none. With the assumption that that way he will be "competitive." Again, why is then surprising to discover that "the whole world" is not perfect, once you implement your part with the assumption it were?
Just because he knows what the "ideal case" is he can't expect that everything he confronts would be ideal.