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

TCP is harder than it looks

jsnell.iki.fi

Post reply on HN
Print view View original

41–50 of 66 posts

Re: TCP is harder than it looks

#41

Post by sillysaurus3 »

oranlooney wrote: post #39
sillysaurus3 wrote: post #37

Earlier quoted context omitted.

Otherwise, buggy programs will depend on these flags being ignored, and you won't be able to use them later for new features. I don't understand why that's true. Just add the new flag and use it for your new feature. Aren't buggy programs who were already sending the flag responsible for their own bugs?

Yes and no. If you push an update and sysadmins all over the world dutifully upgrade and immediately notice programs breaking, their first thought is not going to be "oh, those programs must have had latent bugs." No, they're going to blame you. Besides, having stuff work correctly is always more fun than assigning blame, and validating flags is an easy way to avoid these scenarios.

Hm, fair enough. To be clear, I wasn't arguing against validating flags. I was commenting about "This kernel function only gets 32 possible bitflags, but since they never validated their flags, they can no longer add any additional flags, ever, because it might break other programs which may or may not even exist."

That sort of mentality seems like it would push designers in the direction of poor design decisions. If a bitflag is the best design for a new feature, but they're prevented from using it out of a sense of "Let's not ever break anything ever," then the result may be a bad design that people are stuck with for the next 50+ years, which seems objectively worse.

But my reaction is based on theory and not backed by experience, so it's probably unfounded.

Re: TCP is harder than it looks

#42

Post by coderjames »

sillysaurus3 wrote: post #37
cesarb wrote: post #32

Earlier quoted context omitted.

The lesson is "be strict in what you accept, since the beginning". For instance, a lesson learned by the Linux kernel developers: when adding a new system call to an operating system, if you have a flags parameter (and you should, which is another lesson they learned), if any unknown flag is set, fail with -EINVAL (or equivalent). Otherwise, buggy programs will depend on these flags being ignored, and you won't be ab…

Otherwise, buggy programs will depend on these flags being ignored, and you won't be able to use them later for new features. I don't understand why that's true. Just add the new flag and use it for your new feature. Aren't buggy programs who were already sending the flag responsible for their own bugs?

I would tend to agree with you, but from what I recall Linus' policy is user-space breaking changes are kernel bugs.

Re: TCP is harder than it looks

#43

Post by signa11 »

agumonkey wrote: post #6
leonardinius wrote: post #2

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.

Coursera and stanford mooc helped me understand networking deeper, you might try to apply.

which ones if you could point them out please ?

Re: TCP is harder than it looks

#44

Post by j_s »

MrBuddyCasino wrote: post #18
longwave wrote: post #12

Earlier quoted context omitted.

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...

That was quite impressive, not sure I would have found that out. I know I'm stretching my luck, but since those were great reads - do you have a 3rd best TCP timeout story? :)

For more stories, see the hacker news discussion on that SSH packet corruption issue: https://news.ycombinator.com/item?id=4709438

Re: TCP is harder than it looks

#45

Post by xxpor »

sillysaurus3 wrote: post #37
cesarb wrote: post #32

Earlier quoted context omitted.

The lesson is "be strict in what you accept, since the beginning". For instance, a lesson learned by the Linux kernel developers: when adding a new system call to an operating system, if you have a flags parameter (and you should, which is another lesson they learned), if any unknown flag is set, fail with -EINVAL (or equivalent). Otherwise, buggy programs will depend on these flags being ignored, and you won't be ab…

Otherwise, buggy programs will depend on these flags being ignored, and you won't be able to use them later for new features. I don't understand why that's true. Just add the new flag and use it for your new feature. Aren't buggy programs who were already sending the flag responsible for their own bugs?

No: https://lkml.org/lkml/2012/12/23/75

Re: TCP is harder than it looks

#46

Post by 1945795 »

signa11 wrote: post #43
agumonkey wrote: post #6

Earlier quoted context omitted.

Coursera and stanford mooc helped me understand networking deeper, you might try to apply.

which ones if you could point them out please ?

https://www.coursera.org/course/comnetworks

http://networking.class.stanford.edu/

Re: TCP is harder than it looks

#48

Post by AshleysBrain »

nabla9 wrote: post #31

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

I'd say one of the lessons is that even a supposedly well-standardised system sees hundreds of implementations (or more!) then the accumulated bug baggage can still make it hacky with per-platform code. For comparison consider web browsers, which although are far better these days than they used to be, between just Chrome, Firefox, IE and Safari there's a bunch of quirks and platform-specifics, so I can imagine worldwide TCP deployments are "interesting".

Where possible hacks should be applied only where necessary, e.g. the specific software versions affected only, and exclude fixed versions. Then hopefully in the long run the old buggy versions die out and the hack can be removed... but as the article says, over a network it's not always possible to identify when to apply a hack.

Re: TCP is harder than it looks

#49

Post by acqq »

viraptor wrote: post #29
acqq wrote: post #28

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…

> You have to plan to handle the special cases or not be surprised that you can't handle them. What do you propose then? You send valid traffic and get a completely broken response - I don't see any space left for handling special cases here. Like they said in the article, it's the first packet and you have no information about the other side yet. This is not something you can avoid/workaround.

As soon as you think "I send a valid packet, everything must work" you're missing the point. Even OP at the end worries about the actual client communication actually not working. At the end, it's not who's "theoretically" right, it's "can you make it work given the real world limitations" that include the implementations not tested with your "clever better than the competition dynamic timeout modification." It can be clever, but be clever more and plan for the cases when it is against the real life limitations. And don't cry foul. It's you who move into less tested territories, expecting to be better than the "competition".

The same as I don't complain about the herd reactions here. They are probable, therefore expected.

Re: TCP is harder than it looks

#50

Post by [deleted] »

xxpor wrote: post #45
sillysaurus3 wrote: post #37

Earlier quoted context omitted.

Otherwise, buggy programs will depend on these flags being ignored, and you won't be able to use them later for new features. I don't understand why that's true. Just add the new flag and use it for your new feature. Aren't buggy programs who were already sending the flag responsible for their own bugs?

No: https://lkml.org/lkml/2012/12/23/75

[deleted]
Post reply on HN