Author Topic: 2015/12/23 - Blockland r1984  (Read 168407 times)

Well you see the problem is that you're still using old dup.
we have the new duplicator, (newplicator) the "old" duplicator (duporcator) and the "old old" duplicator

The old duplicator and the old old duplicator basically copy the color directly, if you have your paint can as a fx for some reason it breaks it and I don't know why.

If you set a brick's color ID to a color ID that's not defined in the colorset, it's 1 0 1 0. As in, a completely invisible magenta.
This would happen if you set the color to the 64th color in a 63 color colorset.

Random thought: what is the maximum total length of a BlobChunkEvent? I was assuming it to be 450 byte in total, but it obviously isn't based on what I'm seeing in the netgraph while loading. In fact it seems to be about 30 byte longer. So 1024+480 byte will still overflow the packet.

This could explain why people are only getting completely stuck loading while others are chatting on the server. Loading on it's own sends 1440 byte packets, + >60 byte chat message = fail.

You should probably change it to 400 instead. This will fix the problem of netevents getting stuck completely!



But this is only half the issue - fast packets can still break the connection while loading

I've noticed a pattern, it might help with debugging  the load freezing. While frozen, dnetsetlogging(1); always looks like this:



There will always be one or more "not recv" between the large batches of packets. It's frozen until this missing packet finally arrives (or forever)

You might be able to fix this by just disabling fast packets if a client can't keep up (check distance between missing packet and current sequence number)

Unless it is already fixed by the patch above (maybe overflowing the packet corrupts sequence number somehow?)


Noone got stuck on my server all day so far.
« Last Edit: December 25, 2015, 04:34:54 PM by Zeblote »

Random thought: what is the maximum total length of a BlobChunkEvent? I was assuming it to be 450 byte in total, but it obviously isn't based on what I'm seeing in the netgraph while loading. In fact it seems to be about 30 byte longer. So 1024+480 byte will still overflow the packet.

This could explain why people are only getting stuck loading while others are chatting on the server. Loading on it's own sends 1440 byte packets, + >60 byte chat message = fail.
Aagh, numbers!

Froze on another server, got this pattern instead:



Still the same problem, missing a single packet that doesn't bother to arrive.

Testing a few things on heed's server with ~40 players. What we've done:

1) Change size of blobchunkevent from 450 to 400 (edited exe, link here if someone else wants to test no longer necessary with version 1985);
2) Run a script to periodically un-stuck clients with the missing packet bug (this is only a hack and you need to find the actual problem)

function fastPacketFixLoop(%bool)
{
   cancel($FastPacketFixSchedule);
   $Pref::Net::FastPackets = %bool;

   if(%bool)
      $FastPacketFixSchedule = schedule(8000, 0, fastPacketFixLoop, !%bool);
   else
      $FastPacketFixSchedule = schedule(600, 0, fastPacketFixLoop, !%bool);
}

fastPacketFixLoop(true);



So far

1) people have stopped complaining about loading freezes
2) the server has stopped crashing with runtime errors

This might be getting somewhere ?!
« Last Edit: September 18, 2016, 10:22:19 AM by Zeblote »

now you see zeblote is pretty cool so of course he figured out the runtime errors

please let me bear your child zeblote

It's still possible blockland is fooling us and it starts crashing again tomorrow

It's not a complete fix ready to add in an update either

It's still possible blockland is fooling us and it starts crashing again tomorrow

It's not a complete fix ready to add in an update either
Well Randomizer is running your fix and it usually crashes with the current update after 15+ players. We will see if this fix works.

Does it still crash with the fix?

battlemix will be running the fix btw
i'll report in with any runtime errors if i get any

Does it still crash with the fix?
Not yet, it's been up all day with 10+ people though.

From what I've been experiencing it seems the crashes are found when a client is downloading files (without the fix)

Yes, that's why I think the two problems are related. It's quite possible the runtime error is caused by the packet overflowing or by the server building a too large queue/whatever happens on the server side if the client has the missing packet bug.

For all we know, it was added with the update that changed things about loading and happens only while clients are loading.