...to settle a bit of an Internet bust-up. The conversation between "TobiHeidi" and myself, "wm": https://www.mochiads.com/community/forum/topic/realtime-multiplayer-flash-game#29 Thoughts? I'm not looking for backup for my statements, but neutral thoughts from people who program networked games day in, day out.

C is faster than Java.

/Discuss

What is there to discuss?

I think it's clear that TobiHeidi has no idea what he's talking about. He claims Counter-Strike uses P2P (which it doesn't) and that packet loss is 'very rare' in the wild (ie not your typical LAN) which isn't true either.

Edit: Doh, you're WM - I didn't understand that, hehe. Well, using any protocol on a lossy Wireless connection (which isn't that unrealistic to expect) will yield huge amounts of spiky losses of packets, and ADSL and modems are not exactly immune to it either.

Don't feed the trolls, I'd say. :)

I have a real-time server (C# with IOCP sockets) that's I've tested with 100 flash clients. I'm not sure where you got the idea that you can't use TCP. You might be assuming packet loss is high and that dropped packets happen so much that it's a problem. I haven't seen this myself even with testing with people across the world. He's right about the once a month stuff. I honestly never see my RTT jumping. It's normally constant for each client.

You have to be careful with TCP connections. A lot of beginners will flood the socket. It's a good idea to run a fixed update. I use 100 ms physics updates and I throttle packets between 5 and 10 packets/second. If you come from a UDP background you might be trying to shove 30 packets down the line, but don't. Naggle the packets yourself and send them messages in batches like I said.

Having helped a few people online with the idea of flash networking I found out a lot of them had misconceptions or completely set up things wrong and were asking for trouble.

// edit I have to go home. I'll finish reading your posts later.

Is this ideal for something that needs to be very low latency like a space shooter or FPS game though Sirisian? I just find it hard to believe that anything like this wouldn't be drastically improved by being able to throw out UDP packets as quickly as possible.

I can't agree with what you say about lost packets. Have you tested in the real world where people have line noise and crappy wireless connections and congested networks etc.?

Quote:Original post by wmarsh
Is this ideal for something that needs to be very low latency like a space shooter or FPS game though Sirisian? I just find it hard to believe that anything like this wouldn't be drastically improved by being able to throw out UDP packets as quickly as possible.

Unless you can advance simulation despite missing packets, there is no inherent benefit in using UDP.

Quick has nothing to do with real time. Even with UDP, sending packets over flooded connection will make things worse. TCP in this case provides throttling mechanisms, with UDP handling that is up to user.

Real time is about meeting a deadline. In case of games, this means that by the time simulation needs to advance to next step, it has received enough information (not data) to be able to do something meaningful about remote state. If that means skipping missing states, advancing based on prediction, waiting for data, or something else is purely up to what fits the requirements.

The key advantage over using UDP is the ability to define custom recovery mechanism, or not recover at all, instead of using the standardized one implemented by TCP.

Although, it might not even matter, since many connections don't even support it, or tunnel it through other types of connections, especially with increased emphasis on mobile platforms (G3 and related phone connections) and browser (AJAX, and similar).

Most of the time it is considerably more important to mask the effects of latency. For example, most of Windows 7 is not about performance improvements, but about masking Vista's perceived sluggishness using various UI tricks.

My take on it is that if data has arrived corrupted, I no longer want that data. It's too late, I want to move on. I don't want a system that keeps trying to send a packet from the past until I get it successfully, instead I want to act on whatever packets do arrive after that.

I would rather have a client keep predicting the action until it does get a valid update from the server than wait for the network to provide me with an old, correct packet. I understand that none of this happens automatically because I've chosen to use UDP, and that of course the client and the server must define their own ways of dealing with network events like this, but that's what I want!

This is my point really, and I'm sure I've failed to make it clearly: It's not a case of "Ooh, UDP is 20ms faster than TCP! Use that by default", but instead a case of not wanting to use TCP's methods of correction and timing and delivery because they are not suitable for what I'm doing. Looking at what has been happening in online gaming since it has been relevant, I believe that this is the general take on the matter.

Quote:Original post by wmarsh
My take on it is that if data has arrived corrupted, I no longer want that data. It's too late, I want to move on. I don't want a system that keeps trying to send a packet from the past until I get it successfully, instead I want to act on whatever packets do arrive after that.

If you can do that, sure, why not use the optimal method.

There is however another side. Developing a reliable UDP transport is difficult(tm). So usually either third-party library is used, developers do their best, or "better" way is used (TCP). Practical experience shows that often, using inferior, but more accessible choice will result in superior end results, even if sub-optimal.

I like this. It is perhaps the true representation of software development in general. Technical issues are the last of the problem, and easiest to solve.

But as short answer - if you have the choice, the expertise, the time, and all that, then rolling custom UDP networking mechanism may result in better user experience. The word 'may' does not imply that using TCP by itself would be better. For example, home routers can be a disaster for UDP, moreso than TCP.

And since testing and QA may be simply too expensive for the developer(s), they can opt for a tried-and-true inferior solution with better end results.

Quote:Original post by wmarsh
This is my point really, and I'm sure I've failed to make it clearly: It's not a case of "Ooh, UDP is 20ms faster than TCP! Use that by default", but instead a case of not wanting to use TCP's methods of correction and timing and delivery because they are not suitable for what I'm doing. Looking at what has been happening in online gaming since it has been relevant, I believe that this is the general take on the matter.

Yeah, at least that's how they do it in Unreal Tournament and the Tribes II papers (by Frohmayer) describe the same procedure.

It's possible that a packet isn't delivered and meanwhile the simulation has advanced and retransmitting the packet is pointless because it contains data that is out of date. As far as I understand, this isn't possible to do in TCP.

I guess that's also why most twitch games use UDP.