Is TCP suitable for network game programming consisting of regular positional updates?

Suppose you were forced to use TCP sockets over UDP sockets (ie: something that Silverlight insists on). Would it be possible to create a multiplayer game that involves sending real time positional updates to up to say eight players so that each player could accurately see every other player in real time, even though UDP would be the better protocol to use? Given the option, would you wish to go as far as to开发者_JAVA技巧 select a different technology (ie: Java), simply to gain UDP support?

Thanks, Nick

---

As long as a few milliseconds aren't important i see no reason to use UDP.

---

To receive UDP packets, you must have a public IP address.

To receive UDP packets, you need to be able to listen on a port. Not all frameworks in all environments can do this, often for security reasons and such.

As you describe Silverlight as a target platform, we can anticipate that this won't always be the case for your players.

Use TCP.

As an alternative to Silverlight, you might look at Haxe (or Flash).

(From the comments, there is mention of STUN and stuff; that's an interesting if difficult angle to pursue.)

---

It depends on how fast of real-time you are looking at. For example, if you try to make a space battle, and everyone is close, but moving at a high speed, then you may find that the milliseconds difference makes a difference, but, if you are doing something like an auto racing game then it won't make any difference, so TCP is fine.

So, try it, get some numbers and decide if it is acceptable.

The bigger problem will be the difference in bandwidth, so, if one person is playing over a really slow connection, and everyone else are on very fast connections, then that slower player will be a problem. You may need to scale the updates to the slowest connection, and you may find that TCP/UDP issues are not enough of a concern, as the difference in connection speeds are a far bigger problem.

So, test with various connection speeds, with differing numbers of users, each with their own connection speeds, and see if, as one user, the game is still enjoyable.

UPDATE

It is not bandwidth that will be the concern, but the latency, as was pointed out in a comment. I had picked the wrong term, as several people might be able to respond quickly and be closer to real-time, but one user may be much slower, perhaps on a congested network, slow computer, or whatever, but they may only send updates every 1000ms, whereas everyone else is doing it every 100ms.