Feature #23241

Change the "network" settings for client and server, and network synchronization behavior.

Added by Anunnaki almost 6 years ago. Updated over 5 years ago.

Status:Assigned Start date:08/08/2011
Priority:Normal Due date:
Assignee:- % Done:


Target version:-
Affected ArmA II version:Please select... First affected ArmA II version:
Reproduced by another DH user:No Single / Multi Player?:
I am using some Mods:No BIForumURL:
I am using: NGUrl:
Reproducible for you:No WIKIurl:
Related to content of DLC:


At this time, there are very few settings, how we can make multiplayer games more smooth.
And what is worse, this settings are statics not dynamics, so it is not possible optimize those settings to the data line connection properties.
Furthermore, there is no way, how we can improve/change, how smooth (precise and frequent) clients sends their local object positions (player and his AIs). Those would be still not smoothly.

Right now, we have those settings available in base.cfg (basic.cfg):

So i think, that we need whole new way, how to set network settings more correctly and precise, and allow the game engine to calculate those things dynamically depending on current data line state/properties.

We need whole new parameters, replacing those mentioned above, something like this:

1. How fast is the line (in UPLOAD direction).
maxUploadBandwith = 480000;
default value should be 480000 for clients or playerServers (=+- most of players have DSL upload speed about 480kbps), and value 10000000 for dedicated servers (=10Mbps)

2. How many packet per second can be send to line (in UPLOAD direction) without loose.
maxUploadPacketsPerSecond = 50;
Default value should be 50 on clients, 750 on playerServers, 3000 on dedicatedServers

3. Maximum IP packet size with included headers (TCP or UDP) can be send to line (in UPLOAD direction) without fragmentation.
maxUploadPacketSize = -1;
This is know also as layer 2 frame payload size or MTU size on ethernet frame. Default safe value for all should be 1400, also value -1 should trigger AUTODETECT. Detection should be done by http://en.wikipedia.org/wiki/Path_MTU_Discovery, but there should be hard-coded maximum size to 1492 (that is DSL layer limit size, from this point, some modems are doing hidden fragmentation which is transparent to application (undetectable)). This value should be negotiated when client is connecting to the server. That means all clients should have own independent "maxUploadPacketSize" value when sending packets to server, but also server must have for each client independent "maxUploadPacketSize" in direction from server to particular client.

Next settings should be available only on servers (and transmitted to the clients):

4. Maximum packet per second to single client.
maxUploadPacketsPerClientPerSecondLimit = 50;
Server will never send more packets to one client, than given amount.
Default should be 50, that means 50 packets in every second for one client.

5. At least how oft should every client and server send positional synchronization update packets (UDP packets).
defaultPacketUpdateRatePerSecondForEveryone = 10;
This value should be transmitted to the clients from server, so all computers should use the same value.
Default value should be 10, updates will be send/received at least at rate 10 packets per seconds (=every 100ms).

6. Limit for clients, how many packets client can send to the server.
maxUploadPacketsPerSecond_maxLimitForClients = 50;
Because every client have its own maxUploadPacketsPerSecond value, some of them can have set there too big value, and perhaps too much such clients can flood server data line connection. Therefore, server admins should be able to set max limit for every client in maxUploadPacketsPerSecond_maxLimitForClients.

defaultPacketUpdateRatePerSecondForEveryone should be used as recommended minimum for computer. But when there is enough line capacity available, computer should send updates more frequently to fully utilize the potential of data network line/capacity.

That means when client have enough upload line capacity, he can send his positional updates very oft and precise (perhaps even 150 packets per seconds). So server would have the best possible positional updates (position of units and objects) from all clients at every moment. Than servers will see, how much line bandwidth capacity and packet he have available, to send all of them, or just only some of them to clients.
For every client, positional updates should be send by prioritization, depending on distance between client and those positional updates (i think arma2 server is doing this prioritization already).

From this settings, clients and server should be able independently calculate their line (upload) abilities, and dynamically update and determine, how often and how precise they will send updates to each other, and provide the best game (smooth) experience to MP game.

Related issues

related to ARMA2 Community Issue Tracker - Bug #23555: Interpolation/Animation changes bugged in MP Closed 08/18/2011


Updated by Anunnaki almost 6 years ago

  • Description updated (diff)

Simply every computer knows from:
defaultPacketUpdateRatePerSecondForAveryone = 10;
that he must send at least 10 packets for second with position updates/shootings.
He also knows, how much packets per second, and also how long those packets can be.

He just can use formula like this:
how much packets per second he would use for regular position updates per seconds (UDP packets):
2/3 of maxUploadPacketsPerSecond // but minimum defaultPacketUpdateRatePerSecondForAveryone
how much packets per second he would use for other things (TCP packets):
1/3 of maxUploadPacketsPerSecond
Now he starts fills UDP packets with "frames" (how BIS call this) and send them regularly. When there should be too much move updates, and the UDP packets hits limit 1400bytes, computer should chose from those choices:
1. when TCP packets are not too much used (they are not hitting 1450bytes limit) and there is not bandwidth hit, he can change ratio UDP:TCP to use more packets for UDP and fewer for TCP.
2. when there is no way where to go, than drop some "distant" frames updates

Updated by kju almost 6 years ago

Please add a bit more formatting in your posts.

Right now it is a lot of text and not easy to read (to identify the key parts).

Updated by zGuba almost 6 years ago

  • Status changed from New to Feedback
  • Assignee set to Anunnaki

Updated by Anunnaki almost 6 years ago

How can i edit my ticket ? I am able to edit only following posts, but not the first text section in the ticket.

Updated by Anunnaki almost 6 years ago

  • Description updated (diff)

Updated by Anunnaki almost 6 years ago

  • Description updated (diff)

Updated by Anunnaki almost 6 years ago

  • Description updated (diff)

Updated by Anunnaki almost 6 years ago

Updated - reformated.

Updated by Fireball almost 6 years ago

  • Status changed from Feedback to Assigned
  • Assignee deleted (Anunnaki)


Updated by kju almost 6 years ago


Updated by Anunnaki over 5 years ago

You must make difference between:
1. local game, that includes SP game or MP game when you are hosting the game (so you are server and player at the same time)
2. remote game, that means MP game running on dedicated server or someone other "playerserver" (so you are not server and player at same time)

Because INTERPOLATION works perfectly GREAT in case 1., even in MP game, when you are serverPlayer (hosting the game), but only for you! Other players objects will be still laggy.

In case 2 (MP game on dedicated server), there you must also make difference between:
2a. server AIs and objects (this can be partially solved by settings in base/basic.cfg )
2b. players AIs and objects (own AIs or other players AIs) ... there is no way how to solve this

In CASE 2a, there INTERPOLATION also works nice.
Problem is and always was (from OFP times) in CASE 2b. There INTERPOLATION can't help (would be described below). This is not BUG, this is how is game network engine using player's upload line.
In other words, how often are clients (players) sending their positions (player and his AIs) to the server.

Well, interpolation is possible only when you have enougth positional updates. They must be periodical and often as possible. In SP mode, this is not problem, because all objects are LOCAL, so "SP server" have/knows precise positions of all object at any time.

But in MP, "MP server" knows positions only of its own "controlled" objects. Positions of remote objects (player object positions) must be received periodical and often as much, as is possible. And this is problem, because as far as I know, game network core is working in the same way, as it was in old OFP game (same problem in all BIS games).

To me it seems, that INTERPOLATION works great even in MP, but the current network game engine simple does not have (can not provide) actual players and his AI's positions to game engine (specially in way from clients to server).
Simply sad, current game network core can not fully utilize players upload line to provide the best positional updates to the server, as it should be (or as it is possible on player upload line).

I think, that BIS have recognized this, that it is not possible to make MP smoother (INTERPOLATION can't help here too much), so they temporally turned this OFF for MP, after releasing 1.6final, i hope that they would start on changes in game network core, that game can use full upload capacity on players computers, so the server should have smooth positional updates from clients as their upload lines can provide.

Updated by alef over 5 years ago

Moved from #23555 note 29. The note 12 here was copied into #23555 note 25, removed.


Personally, I have lose about 40 hours of clean time to try "play" with all server settings in base.cfg (basic.cfg).
I was comparing what different I will see between DEDICATED server and HOSTED server ("playerserver"). This was done on 100Mbit FD LAN.

There is simple no way, how to make better smooth game by playing with those settings, even when server generated traffic around 12MBit per player from server on LAN game. In case of so much positional updates, clients see all objects just standing on place (not cause by server line or CPU overload, usage was very low compared to HW limits).

Of course, there was some improvement in smooth move, but this was only on server controlled objects. Other players AI was still laggy and not smooth (perhaps clients should sets its own base.cfg too with better values ... I would test that next time).

Anyway, by setting in base.cfg on server, where was problem to determine, what is the best. When I set it too high, it was looking smooth, but when other players was connecting and game was expanding, traffic was too big to handle for clients, and it was back laggy.

When I set MinErrorToSend=0.00001; , engine will create great amount of positional updates internally (i think BIS call this "frames" as "frame update").
But then how set optimally MaxSizeNonguaranteed ?

In case MaxSizeNonguaranteed=64, game was nice almost smooth, but with more players and objects, the amount of packet was very high and there was packetloose i think, because game starts be laggy again.
In case MaxSizeNonguaranteed=1400, there was no packet lose even many players was connected, but packets was sending no so often (very rate I could say) so game was still not smooth.

So as you see, those two main parameters are useless, because they are STATIC. What we need is that those parameters should be calculated "on the fly" dynamically by game network engine. When there is not so much objects and clients, there can be MaxSizeNonguaranteed=32 and packets can be send very very oftly. When UPLOAD is hittig his limits, game should dynamicaly linear adjust MaxSizeNonguaranteed to MaxSizeNonguaranteed=1400. So, there should be less frequent updates, but no packet lose.

There is also some hard coded frequency, how often should updates be send for objects (related to distance from player). This frequency is I think linear with MinErrorToSend=0.00001; . At this values, closer objects are send too often (big overhead, not necessary), and distant objects are still not send as often, as it would be smooth.

I hope I have expressed my self clear, English is not my native language (Czech).

Updated by Anunnaki over 5 years ago

So far, I was able to find and specify two different issues, which are responsible for jerky motion in MP:
http://dev-heaven.net/issues/24034 ... solved!

When the second issue would be solved, I will do more new tests about how those parameters are affecting the MP game.

Also available in: Atom PDF