Zoning/Chunking

[Xen]

Xinux/Foof,

Would you guys mind looking into the issue where zoning back and forth between two zones eventually locks up the client? I noticed when it happens to me the last thing the world console shows is that the client didn't ack the OP_WorldMsgList packet that was sent. This is somewhat similar to the issue we had the other day when we couldn't enter the game. You guys figured that one out and I'm hoping you can figure this out. Zoning into chunks that haven't been loaded yet seems to work flawless for me, as I ran all over the world without issue. So, I think it has something to do with the client already having a connection in the old zone. I noticed that in live logs, the server sends a disconnect packet right after the client sends its, but on the emu we wait 60 seconds to disconnect. I'm not sure if this is an issue or not.

[Xinux]

I was zoning back and forth today a few times with no issues. You could change the disconnect time down to see if that help's. I won't have any time this week after work so i will only be available while i'm at work.

[John Adams]

Xen, I meant to ask you and keep forgetting. Do our chunks currently have a built-in "shutdown timer"? or once they are loaded, they stay loaded? Maybe destroying the chunk when the last person leaves it might bandaid it for now (?)

[Xen]

[quote="John Adams"]Xen, I meant to ask you and keep forgetting. Do our chunks currently have a built-in "shutdown timer"? or once they are loaded, they stay loaded? Maybe destroying the chunk when the last person leaves it might bandaid it for now (?)[/quote]
Chunks do not shutdown at this point. Players in a chunk aren't even tracked yet, but that should change with multi-client support.

[quote="Xinux"]I was zoning back and forth today a few times with no issues. You could change the disconnect time down to see if that help's. I won't have any time this week after work so i will only be available while i'm at work.[/quote]
It may just be my setup, I have everything running on one computer (Visual Studio, Emu, Client) so that might be causing it. I do notice that if I run the server on my Ubuntu VM (hosted on the same computer) it takes 5 or so zoning's before it locks up. With windows I almost always lock up right the first time.

[theFoof]

I'll look at it later, if that DC packet from the server is directly following a DC packet from the client I'd say we should definitely be sending that. We do handle disconnect packets it looks like, we just need to be sending that packet back to the client as well probably in the handler. Look at UDPServer::HandleDisconnect() and add a call to SendDisconnect().

[John Adams]

Just confirming, login/world/client all on 1 machine (localhost) and I ran through 3 chunks fine, turned around and ran back and instantly locked up client.

Console:

Code: Select all

0000: 00 09 00 41 01 00 08 00 - 00 00 3D 00 0A 20 00 3A  ...A......=.. .:
0010: 80 61 AE 22                                        .a."
18:13:27.057 I Chunk    Received zone request!
18:13:27.057 I Chunk    New zone (-27, 25)
18:13:27.119 I Chunk    Client log: Received VGMID_PENDING_DISCONNECT.
18:13:27.127 I UDP      Client from 127.0.0.1 set to disconnect in 60 seconds: Application
18:13:27.228 E Socket   Unable to read from UDP server socket: An existing connection was forcibly closed by the remote host.
18:13:27.544 E UDP      Packet to client timeout after 300 milliseconds (3 tries, 100 milliseconds each)
18:13:27.545 E UDP      Either there is a lot of packet loss or the client is not acking this packet
0000: 00 0D 00 1E 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
0010: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
0020: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
0030: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
0040: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
0050: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
0060: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
0070: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
0080: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00  ................
0090: 0F 72                                              .r

Is it just me, or does that packet look like it's missing the beginning?

Edit: and a valid one looks different, of course:

Code: Select all

0000: 00 09 00 47 00 00 E9 E1 - 83 33 01 00 00 00 88 15  ...G.....3......
18:12:29.119 I Chunk    Received zone request!
18:12:29.120 I Chunk    New zone (-27, 25)
18:12:29.182 I Chunk    Client log: Received VGMID_PENDING_DISCONNECT.
18:12:29.189 I UDP      Client from 127.0.0.1 set to disconnect in 60 seconds: Application
18:12:29.192 I UDP      New client connected from 127.0.0.1
18:12:29.192 I UDP      Received session request from 127.0.0.1 with connectionID 953606579
18:12:29.278 I Chunk    New Session: Account ID: 1  Session ID: '1'
18:12:29.290 E Socket   Unable to read from UDP server socket: An existing connection was forcibly closed by the remote host.
18:12:29.309 I Net      Client log: Disconnected from Zone Server: localhost:10194
18:12:29.315 I Net      Client log: Attemping to connect to chunk. Chunk Address: localhost:10195; Username: 1;
18:12:29.321 I Net      Client log: Connected to Zone Server: localhost:10195
18:12:29.351 I Chunk    Client log: Login successful to Zone Server: localhost:10195
18:12:29.357 I Chunk     control_text='HELLO REVISION=0 MINVER=3151 VER=3186'
18:12:29.423 I Chunk     control_text='LOGIN'
18:12:32.305 I Chunk     control_text='JOIN'

[theFoof]

That 00 0D protocol opcode means it's a fragmented packet, but if you notice right before that the connection was forced close so that's why it's not acking that packet I think.

[theFoof]

Okay so, I'm pretty sure this isn't a packet thing but UDPServer itself. Stop() is being called which kills the read/write threads. So the chunkserver isn't really doing anything after that happens.

The error is originating from Socket.cpp line 377. No clue why we're getting an error there yet. But pretty sure this is a net problem. The reason we were able to zone fine ironically was there was a bug where we were duplicating chunks. That created new UDP servers each time which worked fine, but whenever this error occurs the Chunk's net stuff is boned.

I'm really not familiar with net code at all so this is a pretty foreign thing for me to try and fix lol. If someone else has any ideas post away.

[John Adams]

Thanks for looking into it, Foof. All this low-level stuff is our Foundation code so Scat will have to take a look - and hopefully between he and I, we can get the functions documented so it's clear to all what's going on.

[Xen]

[quote="theFoof"]The reason we were able to zone fine ironically was there was a bug where we were duplicating chunks. That created new UDP servers each time which worked fine, but whenever this error occurs the Chunk's net stuff is boned.[/quote]

I can't access the SVN log right now, but I believe I fixed that issue a couple days ago, right? I kinda chuckled when I saw it, because it made sense why it was working so great (creating a new ChunkServer). I only noticed it because I was looking at my server log and noticed I was up to port 10199 and I had only been in two chunks.

So, any idea why this problem doesn't occur as frequently on linux? I would think it would happen exactly the same way.