Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002045Zandronum[All Projects] Bugpublic2015-01-02 17:152018-09-30 22:59
ReporterLeonard 
Assigned ToTorr Samaho 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version2.0-beta 
Target Version1.4Fixed in Version2.0 
Summary0002045: Client doesn't seem to receive the end of a snapshot under certain circumstances.
DescriptionOn certain maps, when connecting to a server, the client seems to miss the "%s has connected" string and the end of his snapshot.
Because of this the client gets stuck in his receiving snapshot stat until it sends a missing packet request.
So far I have only been able to reproduce this on the d2dmX and d2ctfX maps from skulltag.
Steps To Reproduce-Start a server with skulltag_actors.pk3 and skulltag_data.pk3
-Change the map to d2dm1
-Connect to this server
-You will not receive the end of your snapshot unless you make the server send you a new packet which will trigger the client to send a missing packet request and to do so simply enter "say something" in console.
Additional InformationThis only happens in 2.0, I couldn't reproduce it on the latest 1.4 (150102-1340M).
Attached Files

- Relationships

-  Notes
User avatar (0011224)
Torr Samaho (administrator)
2015-01-02 17:22
edited on: 2015-01-02 17:24

I noticed this effect as well. It shouldn't be limited to 2.0, but for some reason seems to happen less often in 1.x. I'm pretty sure what is happening is the following: The client can't notice when it's missing the latest packet from the server, since the check for missing packets just checks when a packet with a number N is received whether all packets with lower numbers have been received yet. Thus, if the packet with the end of the snapshot is lost during transmission and nothing happens on the server (e.g. no active players on the server), the server doesn't send more packets to the client and the client won't ask for the missing packet since it doesn't know that it's missing something.

I'll see what I can do about this.

EDIT: As temporary workaround enter the menu and exit it again. This will make the server send you at least one additional packet and the client will request the missing packet.

User avatar (0011226)
Leonard (developer)
2015-01-02 17:56
edited on: 2015-01-02 17:56

I understood this, but what I'm talking about, in 2.0 on d2dm1, so far have been reproducible 100% which makes it sound like the server doesn't send the packets correctly instead of simply having them lost during transmission like you said.
I should also precise that I reproduced this on a local server, so the fact that it happens 100% of the time on this specific map I mentioned makes me doubt this is a simple packet loss.

User avatar (0011228)
Torr Samaho (administrator)
2015-01-02 18:55

I don't know yet why the packet loss happens in 2.0 in an almost reproducible manner, but fixing the issue I mentioned will make the client get the end of the snapshot eventually (fix is committed).
User avatar (0011237)
Torr Samaho (administrator)
2015-01-03 13:38

The reason why the packets are dropped seems to be the burst of packets generated by Water's sound table: a15cb89a8f98f540f0553229ba411b7493a50a91

I'm not sure though why this is different in 1.4 and 2.0. Were you using exactly the same wads/pk3s with both? In particular, did you have the same stuff in your announcer and skins directory?
User avatar (0011238)
Leonard (developer)
2015-01-03 14:55
edited on: 2015-01-03 15:14

Yes I used the same map and wads to test this on and I never use a skin/announcer folder while testing.

EDIT: That doesn't explain however why it happens so much with d2dm1 but never on map01 with the same wads loaded.

User avatar (0011242)
Leonard (developer)
2015-01-03 16:35
edited on: 2015-01-03 16:37

While I used the same wads on both 1.4 and 2.0, I didn't only use the wads reported in the steps to reproduce, my bad.
After removing those extra wads, I couldn't reproduce it anymore.
I used jumpmaze wads to obtain such a result.
Here's the list:

skulltag_actors.pk3
skulltag_data_126.pk3
jumpmaze.wad
jumpmaze_prm2.pk3
jumpmaze2_v7c.pk3


I can guarantee you the issue will happen with these wads loaded, and yet this is doesn't even come close to the long list of wads that are hosted on the GV jumpmaze server for example.

You were also right about the sound table, on the map d2dm1, the line

    if (( pBuffer->ulCurrentSize + ( ulSize + 5 )) >= SERVER_GetMaxPacketSize( ))

at SERVER_CheckClientBuffer in sv_main.cpp is triggered 15 times systematically but after changing the function SERVERCOMMANDS_SendSndinfoLookupTable to only call command.sendCommandToClients after the for loop, this is only triggered 3 times and fixes the d2dm1 issue for me.

All of this of course ommitting your snapshot recovery fix.

Now that I found this, I remember that map63 from the given wad list always causes packet loss while receiving a snapshot in 1.3, even locally and after checking, this map triggers the line over 100 times (seriously).
I think there might be a problem caused when the line is triggered many times.

User avatar (0011245)
Torr Samaho (administrator)
2015-01-03 19:13

Quote from Leonard

at SERVER_CheckClientBuffer in sv_main.cpp is triggered 15 times systematically but after changing the function SERVERCOMMANDS_SendSndinfoLookupTable to only call command.sendCommandToClients after the for loop, this is only triggered 3 times and fixes the d2dm1 issue for me.

sendCommandToClients must be called for each instance of NetCommand. If you move "command.sendCommandToClients ( ulClient, SVCF_ONLYTHISCLIENT );" behind the loop the code doesn't make sense anymore. Instead of sending the size (happens before the loop) and each entry (happens inside the loop), you will just be sending the size twice. Of course, this needs less traffic, but is absolutely not what we want.

Nevertheless, this sounds as if the current sound table approach is infeasible and either needs to be fixed or removed.
User avatar (0011250)
Leonard (developer)
2015-01-03 20:08
edited on: 2015-01-03 20:16

Sorry, what I intended by doing this was to have only one instance of NetCommand and so one sendCommandToClients call, I guess this was an oversight on my part.
Properly doing so reduces the triggering of the line (from 12 to 5 in my specific case) yet does not fix the snapshot issue.

User avatar (0011251)
Torr Samaho (administrator)
2015-01-03 20:21

Unless you change how the clients parse SVC2_SNDINFOLOOKUPTABLEENTRY, one instance of NetCommand is not enough here. And I don't see any valid optimization that would reduce the net traffic by more than a factor of two like you indicate (12 to 5). Please post the code snippet you used.
User avatar (0011252)
Leonard (developer)
2015-01-03 20:50

// Send the first index of zero as the table header.
    NetCommand command ( SVC_EXTENDEDCOMMAND );
    command.addByte ( SVC2_SNDINFOLOOKUPTABLEENTRY );
    command.addShort ( 0 );
    command.addShort ( static_cast<int>( S_sfx.Size( ) ) );
    //command.sendCommandToClients ( ulClient, SVCF_ONLYTHISCLIENT );

    // Send every sound.
    for ( int si = 1; si <= soundTableSize; si++ )
    {
        //NetCommand command ( SVC_EXTENDEDCOMMAND );
        command.addByte ( SVC_EXTENDEDCOMMAND );
        command.addByte ( SVC2_SNDINFOLOOKUPTABLEENTRY );
        command.addShort ( si );
        command.addString ( S_sfx[si - 1].name.GetChars( ) ); // Send index 0 as 'slot 1', the client will know what to do.
        //command.sendCommandToClients ( ulClient, SVCF_ONLYTHISCLIENT );
    }

    command.sendCommandToClients ( ulClient, SVCF_ONLYTHISCLIENT );

Instead of creating a new instance I just put the next entry in the first one.
User avatar (0011253)
Torr Samaho (administrator)
2015-01-03 21:06

This will mess up the packet splitting. Since you only call sendCommandToClients once, the packet may (and will in case the sendCommandToClients calls in the loop would have split the packet) get bigger than allowed by sv_maxpacketsize, which will greatly increase the chance of packet loss. It may get even bigger than MAX_UDP_PACKET, which will make it impossible to send the full packet (not to mention that the add* commands will write into unallocated memory in this case).

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: No one explicitly supports this issue yet.
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2015-01-02 17:15 Leonard New Issue
2015-01-02 17:22 Torr Samaho Note Added: 0011224
2015-01-02 17:23 Torr Samaho Assigned To => Torr Samaho
2015-01-02 17:23 Torr Samaho Status new => assigned
2015-01-02 17:24 Torr Samaho Note Edited: 0011224 View Revisions
2015-01-02 17:56 Leonard Note Added: 0011226
2015-01-02 17:56 Leonard Note Edited: 0011226 View Revisions
2015-01-02 18:55 Torr Samaho Note Added: 0011228
2015-01-02 18:55 Torr Samaho Status assigned => needs testing
2015-01-02 23:35 cobalt Target Version => 1.4
2015-01-02 23:35 cobalt Description Updated View Revisions
2015-01-02 23:35 cobalt Steps to Reproduce Updated View Revisions
2015-01-03 13:38 Torr Samaho Note Added: 0011237
2015-01-03 14:55 Leonard Note Added: 0011238
2015-01-03 15:14 Leonard Note Edited: 0011238 View Revisions
2015-01-03 16:35 Leonard Note Added: 0011242
2015-01-03 16:37 Leonard Note Edited: 0011242 View Revisions
2015-01-03 19:13 Torr Samaho Note Added: 0011245
2015-01-03 20:08 Leonard Note Added: 0011250
2015-01-03 20:16 Leonard Note Edited: 0011250 View Revisions
2015-01-03 20:21 Torr Samaho Note Added: 0011251
2015-01-03 20:50 Leonard Note Added: 0011252
2015-01-03 21:06 Torr Samaho Note Added: 0011253
2015-03-29 20:20 Dusk Status needs testing => resolved
2015-03-29 20:20 Dusk Fixed in Version => 2.0
2015-03-29 20:20 Dusk Resolution open => fixed
2018-09-30 22:59 Blzut3 Status resolved => closed






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker