"trying to send too large non-guaranteed message" spam in RPT

[tRiKy_ch 26]

hi everyone,

i've got a problem on my linux dedicated server after the 1.70 update (and after fixing the steamclient.so issue ) my server started to spam this on RPT

 

21:44:00 NetServer: trying to send too large non-guaranteed message (1360 bytes long, max 1348 allowed)
21:44:00 Message not sent - error 0, message ID = ffffffff, to 435978474 (triky)

repeated for every connected player (even for headlessclient) and maaany times per second (fyi: i din't paste the entire log but is growin something like 20MB/hour, spamming this message)

 

tried to increase MaxSizeNonguaranteed parameter but still present

 

[I.Gash 2]

Not showing up in my logs even though we both had the same steamclient.so bug and fixed it the same way. As far as I understand the maxsizenonguaranteed is a parameter for scripts to adhere to when sending messages. Sounds like a script or mission issue. Does it happen when no maps or addons are loaded?

 

Here's another who had the same issue with some BI dev responses:

Basically It seems that a high size value can cause some rubberbanding and sync issue relieve but can cause your scripts to exceed the max ethernet maximum transmission unit which would cause segmentation. In the thread someone suggests a max size of 1480 (+20 for IP headers)

[tRiKy_ch 26]

hi thank you,

i've already saw that and already tried to change the MaxSizeNonguaranteed value, it changes the "byte" values of the error code but still "too long"

 

it happens on liberation takistan (no tried other maps) i manage this server longer than 4 months and literally never saw this kind of error (and spam :)

 

however last night the "spam" stopped suddently itself while we playing and without changes, so now i suspect it could be more a network rather than arma issue

 

 

[I.Gash 2]

Could very well have been a network error. The maximal MTU of your network may vary depending on the technologies you are connected with (ethernet usually having a smaller MTU than glass fibre) I'm not sure if the arma or steam server detects the MTU but if it does, and somehow your router or switch reports the MTU being smaller than standard values it would result in error messages like that. A router will always try to avoid packets bigger than the smallest supported MTU size in order to avoid fragmentation of packets.

[akalegman 10]

I can confirm this problem. Since the Jets DLC patch (v1.7.0) my server RPT log has been spammed with the exact message you are receiving. After doing some testing it seems that frequent diag_log calls in general could be part of the problem. We are running OCAP in debug mode which outputs quite often. I was also using diag_log to ouput some statistics during the testing of a mission. The output reads as normal for a few lines then the rest is the error message mentioned above.

 

Like you I have also adjusted the server performance settings to no avail. I can also confirm that before this the same mission had no issue whatsoever in the RPT even after running for over an hour solid.

 

The only thing that has fixed it so far is just by not outputting anything frequently to the RPT. Which is kind of a shame as I currently need the information for balancing a combat patrol mission.

[smallfly 10]

I can also confirm this problem. Connecting with only one player to the dedicated linux server leads to 184 RPT lines per second (!), thus easily generating RPT with hundred of megabytes. Mission was fine the last 4 months. This errors came up within the last 2 weeks (no exakt date known).

 

Because of the answers above I replaced all my diag_log commands by the comment command. But this does not change anything. Thus I dont see any relationship to heavy usage of diag_log command.

12:54:29 NetServer: trying to send too large non-guaranteed message (1360 bytes long, max 1348 allowed)
12:54:29 Message not sent - error 0, message ID = ffffffff, to 30793507 ([JgZg-A]Schmitt)
12:54:29 NetServer: trying to send too large non-guaranteed message (1360 bytes long, max 1348 allowed)
12:54:29 Message not sent - error 0, message ID = ffffffff, to 30793507 ([JgZg-A]Schmitt)
12:54:29 NetServer: trying to send too large non-guaranteed message (1360 bytes long, max 1348 allowed)
12:54:29 Message not sent - error 0, message ID = ffffffff, to 30793507 ([JgZg-A]Schmitt)

 

[tRiKy_ch 26]

i re-confirm too, last night started again

when i checked the RPT is growed to something like 260 MB on about 3 hours

 

@I.Gash i could expect that on an "homemade" server, but in fact we are on a "professional" host (OVH). howewere this provider set up various antiddos firewall, so my suspect about the network are now on this

[smallfly 10]

I checked two different missions on the same server with the same conditions (only one player connected = me). The RPT spam did not arise with a simple mission of another clan mate. With my own complex mission with many dozens of scripts the error came up. But the errors havent been there ~2 to 3 weeks ago. Identical mission. Very annoying since the RPT spam errors are not very helpful. It would be very nice to know what content those critical packages are carrying.

I checked if my publicVariable commands are the problem. But those work fine and there execution is not related to the amount or point of time of the error messages. But since I am alone on the server, even no enemy spawned yet, I cannot imagine its a bandwidth/lag issue ^^

[tRiKy_ch 26]

so the only confirmation we have 'til now it is all started with the 1.70 update

[Tonmeister 14]

i can confirm this as well. I went through a recent mission removing all my scripts and the error persists. never happened before, and seems my message is only 20bytes over the limit.

[sarogahtyp 1108]

Idk what that is but I can tell that I don't have that problem. That's not very helpful for you but it seems to be no general problem.

I m running domination 3.74 with extdb3 and vcomai as server side mods and 3 HCs on a centos 7 4 core virtual server with 1GBit connection which is hosted by an professional provider as well.

sent from mobile using Tapatalk

[prionic1 0]

I also had this issue on a dedicated server I've set up this morning. I don't know if this was happening prior to 1.70 as I wasn't running a server then. I have some basic scripts in the mission and it has a bunch of mods... I can try running a vanilla server and see what happens tomorrow? Local network. Dedicated Server and Client on one box and another client on a separate box.

 

NetServer: trying to send too large non-guaranteed message (1360 bytes long, max 1348 allowed)
Message not sent - error 0, message ID = ffffffff, to 1875484644 (jerky)

 

[Tonmeister 14]

So for me, I've been able to narrow the problem down, and it was due to the RHS US M113 throwing an error when attempting to turnout as driver. Had to deconstruct an entire mission to find this rat. I was convinced it wasn't the mission scripting once the entire mission was stripped to just the sqm, leading to an object placed in the editor.

[tRiKy_ch 26]

we often use the m113, i'll take a look on that

 

good catch, thank you

[pabstmirror 34]

Saw this on a mission that contained 4x "rhsusf_m113d_usarmy"

Non-stop rpt errors and very low server fps:

Message not sent - error 0, message ID = ffffffff

[tanaka52 5]

This has been filling my RPT logs since 1.70 released. Running a linux server with or without RHS and it's causing tons of spam for each client. I've tried several basic.cfg settings to no luck as well.

[tRiKy_ch 26]

last night i've found a >700mb log on my server, then went to our FOB and i see someone has spawned a M113

so i'm 100% sure that M113 is the cause of this spamming

 

fyi, i sumbitted a ticket on rhs bugtracker http://feedback.rhsmods.org/view.php?id=3369

 

 

[fourjays 27]

On 21/06/2017 at 11:48 AM, tRiKy_ch said:

last night i've found a >700mb log on my server, then went to our FOB and i see someone has spawned a M113

so i'm 100% sure that M113 is the cause of this spamming

 

fyi, i sumbitted a ticket on rhs bugtracker http://feedback.rhsmods.org/view.php?id=3369

 

 

Thank you! I've been trying to find the cause of this issue for months then stumbled across your post and confirmed this was what was causing it. All along I've been thinking it was something wrong with the server hardware or setup. Wonder if RHS will actually fix it.