Server freeze, unable to deliver data issue

[half-lifeer]

Hi.

Server sometimes has a bug where, after players leave, the dedicated server stops sending the correct packets to the master servers. (Hypothetical, because for example server monitor in 333network become unavailable).

The following messages appear in the dedicated server log:

[k_EPacketType_EntityInit] Reinitialized 301 entity
[k_EPacketType_EntityInit] Reinitialized 302 entity
[k_EPacketType_EntityInit] Reinitialized 673 entity
Server: Client '_real IP address_' has provided an identification tag:
    Tag match: 1 | Version match: 1
Server: Sent initialization info to '_real IP address_' (2k)
**Unable to deliver data to client '0.0.0.0', disconnecting.**

The player does not actually join the server, but after this attempt, the server freezes and shows the "Unable to deliver data" message.

The server is still visible in the server search list. The only way to fix it is for someone to join the server.

If you need more information, we could try to catch the bug, and send you RPT file if it's help, but I am not sure, cause console didn't close in that moment.

[DreamyCecil]

I'm really confused by the overall issue and have no idea what the reproduction steps would be like.

1. Can you confirm whether this is an issue with vanilla dedicated servers in general or specifically with patched dedicated servers?
2. Can you elaborate on "the dedicated server stops sending the correct packets to the master servers"? What kind of packets is it supposed to send and when?
3. The server is supposed to stay idle when there are no players, so I'm not sure what you mean by "freezing" either.
4. If it supposedly fixes itself after any new player joins, is this really an issue?
5. Have you tried running the dedicated server with ms_bVanillaQuery = 1; in the main server config?
6. What's the game version? The netcode differs tremendously between 1.05 and 1.07.

And if the server doesn't result in a crash, it won't write anything into the RPT file.

[half-lifeer]

I caught the bug, so if you are connecting to the server, and press ESC when you are loading, it starts.

Q1) Can you confirm whether this is an issue with vanilla dedicated servers in general or specifically with patched dedicated servers?
A1) I tried it with the vanilla dedicatedserver.exe, and I caught this too.

Q2) Can you elaborate on "the dedicated server stops sending the correct packets to the master servers"? What kind of packets is it supposed to send and when?
A2) It's just my opinion, because the server monitor that receives the data is down (unconfirmed, because I reproduced this bug and the server monitor does not fail).

Q3) The server is supposed to stay idle when there are no players, so I'm not sure what you mean by "freezing" either.
A3) Yes, I mean freezing in the sense of stopping responding to server responses.

Q4) If it supposedly fixes itself after any new player joins, is this really an issue?
A4) Yes, it fixes itself. By the way, it's not a critical issue, but it seems like a sort of feature of the 1.07 netcode.

Q5) Have you tried running the dedicated server with ms_bVanillaQuery = 1; in the main server config?
A5) Now using "off" by default. Does it change anything radically?

Q6) What's the game version? The netcode differs tremendously between 1.05 and 1.07.
A6) It's 1.07. I tried to simulate this in 1.05, but didn't catch it.

[DreamyCecil]

ms_bVanillaQuery is off by default, so, in theory, enabling it should affect the server's interactions with the master server. But ideally it should behave the same.

[half-lifeer]

I put the ms_bVanillaQuery = 1; to the init.ini configuration, and tried to reproduce the issue, and i caught this Unable to deliver data to client '0.0.0.0', disconnecting. again. I think its not a problem, it's a UDP feature.

[DreamyCecil]

Since this is caused by aborting the connection on Esc, I can only assume that the server simply cannot respond to the connecting client because the client severed the connection to the server all of a sudden. I don't know why the client isn't requesting a disconnect. Maybe it actually does but it has to process the requested data before the disconnect, so it still attempts to send it and fails because the client has already disconnected.

So, to me it doesn't actually look like a bug. Unless there's a different issue that's happening that I'm not understanding.

[half-lifeer]

That's right. So, I will watch this "situation".
Don't close this topic please. Maybe someone have a suggestions.
When I receive the new information, ill write here.