Will UDP still be dominant in ArmA3?

[tacticalnuggets 24]

The thread title sort of speaks for itself. I wonder this because as we all know, desynch is a major issue in ArmA2, and correct me if i'm wrong, but ArmA2 still uses UDP. UDP is a pain in the ass to use by itself in a game this complex. (I believe suma said arma used UDP, so i'm assuming arma2 does too)

It is true that UDP is good for FPS games because it needs the info FAST. The problem in arma2 is there is so much data that it puts it on the level of an mmo in its scope. I really think that it needs some sort of balanced mix. Something that will eliminate JIP lag and make the game feel modern again in its multiplayer performance.

If you have any better ideas, please let me know.

[McMick 10]

So the problem is that TCP is too slow because it has to send ACK packets or whatever, so UDP is used to avoid this 2-way communication slowdown. But then UDP is prone to errors, so the solution is client prediction, but that leads to possible discrepancies between what the player sees and what really happens.

So what you're saying is use a mixture of both? I wonder if they could use TCP to relate nearby objects' position/direction/velocity/acceleration/whatever and use UDP for stuff further out? Some range thing would have to be called into play, and any ballistic objects would have to still be handled by UDP at any range, except possibly for artillery and missiles, since they are in the air for a good length of time. Of course I may be sounding like a complete idiot right now, I accept that fact.

Still, I don't know of any action game that uses TCP, can anyone provide an example so we can see that it's at least possible?

Edited September 9, 2011 by McMick

[maddogx 13]

UDP is the way to go and they should definitely stick with it. If implemented properly in the program, all the reliability of TCP can be emulated in UDP without any of the connection blocking issues.

[rfc 10]

I'm not even aware of any such games using TCP ... since QuakeWorld it has been UDP in the industry, if I'm not wrong; and *they* had to predict about 150 to 200ms in those modem times!

[TimRiceSE 10]

um... cant think of a single "FPS" game that uses TCP...

when a packet gets dropped in TCP, all packets received after that dropped one are placed into a queue, nothing else goes through till that dropped packed is received - TCP packets are guaranteed to arrive in order. So if it takes a second to detect, resend, and receive that dropped packet then no other information is coming to the client... clearly not acceptable as then when that information finally DOES come through , its at least a second out of date - is this not desynch?

The only information we care about in FPS games is the current state of the game world, hence UDP wins.

Please excuse any inaccuracies in my TCP knowledge. Its been quite a few years since uni :)

[tacticalnuggets 24]

um... cant think of a single "FPS" game that uses TCP...

when a packet gets dropped in TCP, all packets received after that dropped one are placed into a queue, nothing else goes through till that dropped packed is received - TCP packets are guaranteed to arrive in order. So if it takes a second to detect, resend, and receive that dropped packet then no other information is coming to the client... clearly not acceptable as then when that information finally DOES come through , its at least a second out of date - is this not desynch?

The only information we care about in FPS games is the current state of the game world, hence UDP wins.

Please excuse any inaccuracies in my TCP knowledge. Its been quite a few years since uni :)

TCP is used in many games. Its that UDP is the favorite for FPS's because its so much faster. However, for things like a JIP player joining and lots of data being transferred all at once, I'm pretty sure its causing the red chain headache. The reason for that is every machine demands information and a cascade ensues throughout the network. Something like (for a 50 player server) a 50 man tug of war with a rock in the middle. TCP can resolve this much more quickly because its not about updating the information as fast as possible while not worrying about synchronization so much, but about making a synchronization over the network that happens robustly and at whatever pace it needs. I'm sure they could create a better layer over the UDP to simulate this, but why re-invent the wheel if you know what I mean.

Edited September 9, 2011 by tacticalnuggets

[Leon86 13]

Yeah, lets introduce a massive ammount of overhead by using tcp, that'll work great.

[maddogx 13]

I'm sure they could create a better layer over the UDP to simulate this, but why re-invent the wheel if you know what I mean.

Because UDP gives you a whole bunch of freedoms you don't have with TCP.

TCP forces your packets to arrive reliably and in sequence, even when this is not strictly necessary. With UDP you have much more control over the way data is exchanged between clients and the server. Sure, you will occasionally need data to arrive in a similar way to what TCP guarantees, but even then, a custom UDP implementation can save you a lot of headache.

TCP is of course very useful when you're sending large amounts of contiguous data in a non-realtime application (e.g. browers) but for games I advocate using UDP exclusively.

[whisper 0]

Never ever ever use TCP for anything remotely close to real time & interactive

Ever

As simple as that.

FPS? => UDP

You can have side jobs (character general information, config synchronization, connection checkout, etc...) sent over a parallel TCP connection if you want, but any real time data needs to be UDP

Edited September 9, 2011 by whisper

[Drumheller 19]

I don't care what it uses as long as it's vastly improved upon. Once you get over 40 players in a mission REGARDLESS of what's in the mission or on the server, the server FPS absolutely TANKS. From 40-50 players server FPS goes from almost 50 to under 10. From 50-60 you slow to 2-3 FPS max. In a large ArmA unit like mine, when the whole unit shows up and fills the 64 slot server, the entire unit suffers as a result, and this is what ArmA was INTENDED for. Large groups of players killing AI. We have to completely strip almost all scripts and waypoints from AI in order for the server to not crash when we go over 40-45 people. This is the no.1 thing I'd like to see fixed in A3. I'd love to see ~100 people vs AI missions. Could you imagine? /drool

I know A2 is capable of over 100 people but that's without AI.

[PuFu 4600]

I don't care what it uses as long as it's vastly improved upon. Once you get over 40 players in a mission REGARDLESS of what's in the mission or on the server, the server FPS absolutely TANKS. From 40-50 players server FPS goes from almost 50 to under 10. From 50-60 you slow to 2-3 FPS max. In a large ArmA unit like mine, when the whole unit shows up and fills the 64 slot server, the entire unit suffers as a result, and this is what ArmA was INTENDED for. Large groups of players killing AI. We have to completely strip almost all scripts and waypoints from AI in order for the server to not crash when we go over 40-45 people. This is the no.1 thing I'd like to see fixed in A3. I'd love to see ~100 people vs AI missions. Could you imagine? /drool

I know A2 is capable of over 100 people but that's without AI.

this thread is about connections and packages sent over via UDP or TCP...

What does server FPS has to do with it?

[tacticalnuggets 24]

Never ever ever use TCP for anything remotely close to real time & interactive

Ever

As simple as that.

FPS? => UDP

You can have side jobs (character general information, config synchronization, connection checkout, etc...) sent over a parallel TCP connection if you want, but any real time data needs to be UDP

This is exactly what I mean. When A player first connects to a game, the data does not need to get to his client as fast as possible and cause desynch for everyone. Just a gradual guaranteed synch would be good.

[mahuja 12]

There are a few kinds of data, mostly differentiated by how strong guarantees they need on delivery:

-That which is essential and for which ordering is also essential

-That which is essential

-That which expires

"Essential, ordered" is the data for which you need all of it, and you need it in the full order. Like a music file - if you "lose" a few bytes it'll be silent or skip in that period, or if pieces are out of order, presuming the splits happened at codec-acceptable places... Another example is a web page.

Important point: TCP enforces this level of guarantee.

Even in this case, UDP can give you a gain - when tcp loses a packet, it will resend every packet after that one. With a "custom tcp" over udp, you can make it resend only the lost packets.

As a side note, windows' tcp implementation ignores the push bit and does delayed ack anyway, which wreaks havoc where don't disable nagle's algorithm on the sender side. (See world of warcraft)

One example of must-be-ordered data in the arma context, is scripting publicvars. If you can push a,b and when b is updated on the receiver a isn't, that's bad. Stuff breaks.

"Essential, unordered" means that the information has to reach it, but it can process the rest of it while waiting for that information to go through. If you send packets a,b,c by tcp, and packet b is lost, the application will never see packet c until b has been resent and received.

In the arma context, shots fired are an excellent example. You do not want to delay the shots in c from occurring on screen even if you don't have the info from b.

"Expires" is information that goes out of date.

Replaced:

Movement data. Instead of retransmitting the data, you'd rather send newer data. And likely would be sending new data anyway.

Non-replaced:

For VON voice packets, by the time you'd detect it was dropped and retransmitted it, it would already be too late to use it when it arrived - the rest of the sound, perhaps including the parts that came after it, had already been played.

You could introduce a narrow category of non-expiring but non-essential data, but I cannot think of anything in the arma context that fits the category.

And here's the summary:

When you always need the guarantees of ordered essential, you use tcp. When you don't care about performance, you should use tcp for reasons of simplicity.

ArmA is neither, hence they should use udp. You do pay a price when you use tcp.

They could go for a tcp/udp hybrid solution, but that does have some problems of its own, and wouldn't solve much. Assuming they have some ordering support in their udp protocol already, which I would call assuming they are clueful, there is no real gain in tcp.

The only switch they should make is to sctp, but even win7 does not provide drivers, and consumer-grade ipv4 nat routers are unable to forward it.

At least it's not directplay, as was used in the very beginning of cold war assault. That POS is not suitable for anything realtime.

Edited September 10, 2011 by MaHuJa_

[noubernou 77]

In my opinion TCP vs. UDP in Arma is just moving the issue from one place to the other. In Arma right now you already have a problematic system in how they handle lost packets. Right now when packets are lost the entire simulation on all clients will actually travel back in time to match up and continue syncing with other clients. It is sort of the "you only move as fast as the slowest man" issue. So the issue of guaranteeing packets arriving in a certain order is already an issue in Arma. I am not sure if TCP would actually provide any benefits, and actually might be more detrimental in some ways.

That being said, certain portions of the game should not work in the same packet architecture that they do now. There is no reason that sending 1Kb of data via a public variable should desync the entire game process, even a continuous 1Kb/s should not desync the server.

What I would like to see is an improvement in the essential network architecture but provide scripters a method of sending/streaming data that does not follow the same procedures as the rest of the game data. If this is implemented in TCP or UDP I dont think really matters as long as it is asynchronous from the main network stream.