tcp netcode

[Horve]

the german brainfucker with a minefield on his face has managed to place not just one, but two absolutely useless and irrelevant posts here. I want everyone to cherish them for the rest of their lives.

It's a series of tubes.
I have a tendency to believe that jrgp knows what he's talking about more than anybody else here. Except for me, of course.

[Centurion]

http://www.youtube.com/watch?v=suD0AH6aSjE

Skip to 0:58 till it starts singing about german people. GJ

[Neosano]

Obviously it isn't that simple.

god damn it fucking IS!

[FliesLikeABrick]

The biggest problem with TCP for realtime applications is as follows.  This is why UDP is used for
games
voice (VoIP)
streaming real-time movies/content
DNS

The reason:
When a packet is dropped in TCP, the manner in which it is handled would wreak havoc.

Say you have a TCP connection open between computers X and Y, and packet number 5 going from X to Y is lost/dropped because of a network error, noisy DSL line, etc.  Y will miss packet 5, get 6,7,8 etc, but will not actually USE 6/7/8 until it gets 5.  So either it waits for X to retransmit packet 5 after a certain amount of time because Y never acknowledged it, or Y will say "yo, I never got 5!".

Once Y finally gets 5, it will then finally use 6/7/8.  Now keep in mind... the game data stream from X has been frozen completely for this time, sometimes up to half a second when a packet is dropped in TCP. 

Now think about how that will help your gameplay out.

(It won't, it'd make the problems you guys complain about much, much worse).

[-Major-]

The biggest problem with TCP for realtime applications is as follows.  This is why UDP is used for
games
voice (VoIP)
streaming real-time movies/content
DNS

The reason:
When a packet is dropped in TCP, the manner in which it is handled would wreak havoc.

Say you have a TCP connection open between computers X and Y, and packet number 5 going from X to Y is lost/dropped because of a network error, noisy DSL line, etc.  Y will miss packet 5, get 6,7,8 etc, but will not actually USE 6/7/8 until it gets 5.  So either it waits for X to retransmit packet 5 after a certain amount of time because Y never acknowledged it, or Y will say "yo, I never got 5!".

Once Y finally gets 5, it will then finally use 6/7/8.  Now keep in mind... the game data stream from X has been frozen completely for this time, sometimes up to half a second when a packet is dropped in TCP. 

Now think about how that will help your gameplay out.

(It won't, it'd make the problems you guys complain about much, much worse).

are you sure? won't this kind of punish this weak telephone line connections?

either way, I doubt it can get much worse than the current netcode.

[FliesLikeABrick]

You clearly don't know anything about writing network code or how TCP and UDP actually work. 

It is a horrible idea.  There are probably *no* realtime games in the world that use TCP for their netcode, and there's a good reason for it.

I'm not going to bother commenting on your posts in this thread anymore because they're just so incorrect.

[L[0ne]R]

either way, I doubt it can get much worse than the current netcode.

After FLAB's explanation on how TCP works (very educational, thanks ) I can tell you without a doubt: yes, it can get much worse (even though it already is pretty bad). Not just with TCP - even with UDP it can get much worse, and I personally seen this in some games. Just use your imagination a bit.