I have another intersting question: Can you use the same port for both TCP and UDP traffic?

I've once read somewhere that you can have multiple things running on one port, can someone correct/confirm me?

Guaranteed delivery is actually impossible unless your base medium is 100% reliable.</compsci geek>

TCP apparently is fine for a real time game on a LAN, it behaves badly with lag or packet loss though (hiccups!). I think you can use the same port for both TCP and UDP - at least it looks like you can with BSD style sockets (which IIRC virtually everyone uses).

Hey, there seems to be a lot of great information already in this thread, but thought i'd just add my $0.02.

A relevant article:
"The Internet Sucks:
Or, What I Learned Coding X-Wing vs. TIE Fighter"
http://www.gamasutra.com/features/19990903/lincroft_01.htm

A few years old, but still relevant.

Basically his conclusion was (and it is repeated in other articles found all over) TCP acts really really strange, and really is only good for LANS, or completely non-realtime data.

- Jacob

Quote:

Original post by Kevlar-X A relevant article: "The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter" http://www.gamasutra.com/features/19990903/lincroft_01.htm

Thanks for the link, but...

...it's one of those famous articles that is often quoted on this subject, but is misleading/inaccurate/wrong in several places.

In conclusion, you have to ASSUME THIS ARTICLE IS WRONG, and NOT trust the author's conclusions. It is an amusing read, salutory for networking problems, and great if you want an insight into a particular commercial studio - but pretty crap for learning anything useful about networking. It's one of those articles that GDmag/Gama sometimes publishes where they didn't get it properly peer-reviewed, and much of it is made up or just plain stupid.

In defence of the author, he does mention at the start that he is a complete novice on this topic. Unfortunately, many people skim read and don't notice that or forget it by the time they get to the end. His conclusions are fatally flawed because he didn't even bother to RTFM before he started (which is pretty stupid IMHO).

Quote:

Original post by markr Plus using TCP is a good measure for protecting the server from DoS attacks.

I would like to know what difference you think it makes to be using TCP as opposed to UDP here...

Quote:

Ideally we'd have a protocol which provides reliable delivery but does not guarantee the order of messages.

Why don't you read what I wrote above? Reliable delivery is also often undesirable. For instance, Quake 3 relies upon non-reliable delivery, as do many other games.

Quote:

Original post by redmilamber Thanks for the link, but... ...it's one of those famous articles that is often quoted on this subject, but is misleading/inaccurate/wrong in several places. In conclusion, you have to ASSUME THIS ARTICLE IS WRONG, and NOT trust the author's conclusions. ...

Good point, what your saying is true, but it raises the question:
is there a sensible different approach to what you said to reading any programming article?
Heck no! :)

I find outright trusting the advice given by others can be a bad idea, unless you manage to mull over it for a long time, do some more reading, and confirm the findings for yourself.

The findings in this article made a lot of sense for me. The two being:
1) 'TCP can be bad for games, and in ways you might not expect!!'
2) Be sure to _test_ your game in real conditions, not simply on a LAN.

Anyway, glad you mentioned that,
- Jacob

Quote:

Unfortunately, one of the TCP features that is missing from TCP - "guaranteed delivery" - is VERY hard to implement. Do not believe anyone who tells you it is easy - they either haven't implemented it before, or think they have but haven't yet realised that their implementation is broken (subtle bugs).

I respectfully have to disagree.

Perhaps my definition of "guaranteed delivery" differs from yours. Your use of the "'s has me wondering what your definition entails.

-=[ Megahertz ]=-

Quote:

Original post by redmilamber Quote: Original post by markr Plus using TCP is a good measure for protecting the server from DoS attacks. I would like to know what difference you think it makes to be using TCP as opposed to UDP here...

To attack a TCP service itself, you need to make a TCP connection. Making a TCP connection is difficult if you are spoofing your IP address (i.e. not generally possible).

Syn cookies will protect it from syn flooding. And other things like stateful firewalls can be used.

UDP apps need to implement their own syn-like system for remembering half-connected clients. This can be DoS'd by using spoofed UDP packets from random addresses to "max-out" the number of half-connected clients.

Using TCP and UDP is fine though, your server just ignores any UDP from a client which doesn't have an open TCP connection.

TCP of course does nothing to defend against other types of DoS. But there are a lot more tools for defending it.

Quote:

Why don't you read what I wrote above? Reliable delivery is also often undesirable. For instance, Quake 3 relies upon non-reliable delivery, as do many other games.

Ok, point taken.

Mark

Quote:

I used quotes because there are competing similar-but-not-identical definitions :). Basically, IME the really hard part is to implement two things: - dropped packet discovery - retransmit timing

Dropped packet discovery can be handled in the simplest form by using sequence numbers. I'd be interested in hearing the cons to this approach as well as alternatives.

Retransmit timing can be tricky and it varies from application to application and game to game. One thing you have to be careful with (and I think you kinda touched on this) is flooding your connection with retransmits.

Say 50 packets get dropped in succession, those 50 packets are going to get retransmitted again along with any new packets that are scheduled to go out. This can very quickly cause a snowball effect if the packetloss continues for a fair amount of time.

I guess one way to curb this and what TCP does (IIRC) is to trottle back on the sends and send only a few packets out until the acks start comming in as packets get through, then slowly throttle back up to full speed.

Admittedly this is something I've not implemented in my stuff, but I think I can squeeze in a quick hack of adjusting the resend timer up or down depending on whether im recieving acks or not.

-=[ Megahertz ]=-

Quote:

Original post by Anonymous Poster But...I don't see how that's any different from a standard game protocol implemented on top of UDP. There's nothing magical about TCP's connection - most games that implement custom protocols also use connections in (almost) exactly the same way.

The difference is the implementation. Modern implementations of TCP have a very high level of reliability and correctness, and good resistence to DoS (because they have to).

Syncookies is a nontrivial algorithm to try and implement in your UDP protocol (something equivalent).

I'm suggesting it enhances security because the work is already done for you; you have a complete, correct implementation which is already tried-and-tested.

Yes you *could* implement your own system equivalent to syncookies, handshaking etc, but it would involve more work. Network programming is generally rather tricky.

Quote:

Making a connection with them (on a protocol piggybacking on UDP) with a spoofed IP address is just as hard...

If the implementation is of the same quality.

Quote:

Anyway, the very worst DoS attacks of this type the attacker doesn't *care* if you know the IP addresses they're attacking from, because they didn't even hack those machines in the first place.

You missed the point.

If the attacker needs to use a real IP address, he can be rate-limited by the number of connections allowed from the same IP within a given time. The IP can be blacklisted after a certain amount of attempts, forcing the attacker to obtain a new one to try and attack from.

Quote:

It is also worth noting that many attackers don't particularly care about you finding the IP address.

If they spoof their IP, rate-limiting and IP blacklisting are totally irrelevant because every single packet comes from a random IP. In fact they cause you to waste more memory recording all the junk IP addresses. Hence you must use something like syncookies (which does not require you recording any state information about sockets in certain states)

Quote:

Game servers I've managed have received upwards of 4 attacks a day every single day since they went live (although most aren't DoS attacks) - practically never from the same person twice. We simply don't have enough time in our lives to try and prosecute 4 new script kiddies a day, let alone in Russia,

I wasn't suggesting that the server recorded their IPs to attempt to prosecute them, but so that they could be temporarily blacklisted to prevent further DoS. This is entirely ineffective if the attacker uses spoofed IPs.

Mark