0003085: Weapon causes client to completely desync from server

Notes
(0017305) Torr Samaho (administrator) 2017-04-24 06:14	Is it working any better in 2.1.2? If the example is not compatible with 2.1.2, can it be made compatible while keeping the bug in 3.0?

(0017310) Untitled (reporter) 2017-04-24 18:33	The Weapon is not compatible with 3.0 off the bat due to A_SetScale calls. However, after removing all 38 A_SetScale calls (which makes it Zandronum 2.1.2 compatible), the bug still occurs online in 3.0. By testing with 2.1.2, I found something out: Using the weapon's altfire (which produces more reliable desyncs) in 2.1.2 causes the client to repeatedly drop more and more packets until eventually kicking the user for missing more than 1024 of them. For some reason, Zandronum 3.0 fails to register the packet loss and does not kick the client; which results in the erroneous non-synchronous behaviour when the client should, for all intents and purposes, no longer be connected.

(0017423) Torr Samaho (administrator) 2017-04-29 17:30	I tested this on a local 3.0 server and it seemed to work fine, but it generates huge traffic spikes. Please tell me what exactly is necessary to get the client permanently out of sync.

(0017474) Untitled (reporter) 2017-04-30 23:10 edited on: 2017-04-30 23:10	I've figured it out. It turns out that my version of Russian Overkill (and thus, this, as a derivative weapon) forgot to put +CLIENTSIDEONLY on the effects, so network traffic is simply absurd due to sheer actor overload; this is what causes the packet loss. So, with that in mind, I've found a NEW bug, which is that Packet Loss doesn't seem to have a 100% chance of actually registering to the client; sometimes my client simply desyncs without disconnecting to the point where it really is no longer updating with the server, but the client doesn't report the packet loss, which normally earns it a disconnect.

(0017564) Torr Samaho (administrator) 2017-05-07 10:12	Quote from Untitled sometimes my client simply desyncs without disconnecting to the point where it really is no longer updating with the server, but the client doesn't report the packet loss, which normally earns it a disconnect. Can you reproduce this? That sounds like a serious bug we need to fix, but there is not much I can do if it can be reproduced.

(0017607) Untitled (reporter) 2017-05-08 17:58 edited on: 2017-05-08 17:58	In general, a quick guide is that it seems to happen when there's a frankly insane amount (as in, a mod should never ever induce this much) of network traffic, to the point where my client can't actually stay synchronized with the server. The testing weapon, if the altfire is relentlessly abused (testing in a map with high monster density really helps here), it generates network traffic at a rate higher than any mod should; but it makes a good baseline for measuring this. If my client can't keep up with the server, it works about equally badly in both 2.1.2 and 3.0; the /only/ difference is that I don't disconnect in 3.0, even when I clearly should. With that in mind, this does make testing significantly harder; I've had the advantage of using TSPG for this, which means I actually have some amount of network lag; I'd imagine if you're the host of all network traffic you can't desync (since as far as I know you can't desync with yourself). This bug was mostly discovered because of my originally horrifically un-optimized build of Russian Overkill, which caused this kind of thing (due to horrifically large amounts of network traffic), so it's definitely network traffic related. Also, for posterity, the horrific build of RO in question:'http://allfearthesentinel.net/download?file=ro_pb_2.4_zan3.0_fixed.pk3 [^]'

(0017614) Torr Samaho (administrator) 2017-05-09 06:10	Can anybody reproduce this on a local server? I need to reproduce the problem to debug it.

(0017625) Untitled (reporter) 2017-05-11 16:49 edited on: 2017-05-11 16:51	Alright, sorry for the late reply (dealing with other things), but I have a server hosted on TSPG called 'Zandronum Server Traffic Desync Test', which runs 12-in-1 with a horrifically unoptimized Russian Overkill on TAT03, which can consistently obliterate clients with server traffic due to being based on it's laggiest weaponry; I SHOULD packet out as soon as I start shooting, but sometimes the disconnect fails to happen. I'll leave this server up for at least a few days. At this point, I feel the ticket should be renamed to "Zandronum client occasionally fails to recognize missing packets", because at this point, that's as much as I can figure out.

(0017628) jdagenet (reporter) 2017-05-12 05:10	I was unable to reproduce this on a local server using the Bouncing Tester wad, I also joined that TSPG server earlier today and was unable to desync from the server while messing with the various weapons.

(0017631) Untitled (reporter) 2017-05-12 21:47	Alright, at this point I'm convinced that this bug isn't being experienced by anyone else; I think at this point it's safe to mark it as "could not reproduce", especially since this only seems to occur in situations that should not be happening anyway.

(0017694) WaTaKiD (updater) 2017-05-14 20:57 edited on: 2017-05-14 20:57	<WaTaKiD>alrighty so i spammed for roughly 15 seconds, got stuck in connection interrupted for roughly 6 minutes before finally recovering <WaTaKiD>peak was 1.9 mb/s and stayed there until i finally recovered <WaTaKiD>'https://pastebin.com/cqLdpaiv [^]' dumptrafficmeasure, if it matters <Torr_Samaho>Wow, 1.9 mb/s for 6 minutes while you were doing nothings? Now that's a lot of traffic. <WaTaKiD>yep, every minute or so i would hear the gun fire, or an imp would take a step forward, very very slowly trying to get back in sync <WaTaKiD>my chat didnt show up until i recovered, but showed up instantly in the server log 8mb demo: 'https://www.dropbox.com/s/fv48cq1gkcwlmyf/2017.05.14_13.32.29_bouncingtester.zip?dl=0 [^]' binary used was 3.0-r170416-0710 doom2.wad and BouncingTester.wad are the only wads used sv_maxpacketsize was 1024 sv_maxpacketspertick was 64

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2017-04-23 21:50	Untitled	New Issue
2017-04-23 21:50	Untitled	File Added: BouncingTester.wad
2017-04-24 06:14	Torr Samaho	Note Added: 0017305
2017-04-24 06:14	Torr Samaho	Status	new => feedback
2017-04-24 18:33	Untitled	Note Added: 0017310
2017-04-24 18:33	Untitled	Status	feedback => new
2017-04-24 18:33	Untitled	File Added: BounceTester_NoSetScale.wad
2017-04-29 17:30	Torr Samaho	Note Added: 0017423
2017-04-30 15:43	Torr Samaho	Status	new => feedback
2017-04-30 23:10	Untitled	Note Added: 0017474
2017-04-30 23:10	Untitled	Status	feedback => new
2017-04-30 23:10	Untitled	Note Edited: 0017474	View Revisions
2017-05-07 10:12	Torr Samaho	Note Added: 0017564
2017-05-07 10:12	Torr Samaho	Status	new => feedback
2017-05-08 17:58	Untitled	Note Added: 0017607
2017-05-08 17:58	Untitled	Status	feedback => new
2017-05-08 17:58	Untitled	Note Edited: 0017607	View Revisions
2017-05-09 06:10	Torr Samaho	Note Added: 0017614
2017-05-09 06:11	Torr Samaho	Status	new => feedback
2017-05-11 16:49	Untitled	Note Added: 0017625
2017-05-11 16:49	Untitled	Status	feedback => new
2017-05-11 16:51	Untitled	Note Edited: 0017625	View Revisions
2017-05-12 05:10	jdagenet	Note Added: 0017628
2017-05-12 21:47	Untitled	Note Added: 0017631
2017-05-14 19:46	Torr Samaho	Relationship added	related to 0001469
2017-05-14 20:57	WaTaKiD	Note Added: 0017694
2017-05-14 20:57	WaTaKiD	Note Edited: 0017694	View Revisions