[FIXED!!!] CRITICAL Connection Issues

[xinux]

Two separate issues.

1st. camping and reentering the world - LD code i think is causing the hanging that is why i changed it to 1 and 5 so client would disconnect right away.
can test by just camping and logging right back in.

2nd. 4k ping - ghost update packet spam
seemed to happen mostly on zone startup best way to test is log in then /exit the client and restart your world server.

[John Adams]

2nd. 4k ping - ghost update packet spam
seemed to happen mostly on zone startup best way to test is log in then /exit the client and restart your world server.

This is the only thing I am testing, because it is the core of my issue. And now, without changing anything, I cannot get it to happen. Point is (being a good QA guy), reproduce the problem, then apply the fix, and if the problem goes away, it's a good fix. Yet, now I am perfect ping every time. 20 startups now.

[John Adams]

Woop! Just got Ping-o-Death, so I can test the fix

[John Adams]

I had this epic rant all ready to post when I was doing research into this "can't stay connected ever" issue I've been having.. stumbled upon Xinux's magical 200ms last_spawn_update fix. So far, it seems to be working great (until I logged 2 toons in at once, might be some other fluke though).

I update DB Patcher to set SpawnUpdateTimer = 200ms by default, so if you get this patch and start experiencing other issues, let us know here.

I'm just happy to be able to log in and test spells. I was seriously ready to take a mallet to my computer this last weekend.

[John Adams]

Welp, and just like that the Ping-o-Death is back. 3 logins in a row, 4,000 ping. I also noticed during one of the successful connects, /camp cause the Ping meter to spike as well. I can't say I remember that before... but usually we GMs /camp instantly. This is camping and waiting the 20s to completely disconnect.

Hopefully that is a clue to what's going on here.

[thefoof]

Something else interesting I noticed recently while testing my new group stuff, the client still receives packets like normal... other players move around ect, but it refuses to send anything out to the server.

[thefoof]

Believe it or not I think I actually found a fix for this. The problem lies in EQStream.cpp, if a packet gets sent out of seq and the seq is less than the expected seq, we don't send an ack (which I'm guessing is a confirmation the server got a packet? I don't know all this network stuff), added in code to send this and haven't been able to get a single ping o'death since.


The way I found this was I added a packet_debug logwrite for myself to try and track down the last packet the client sends before this happens, and another logwrite kept showing the client sending the same 5 or so seqs repeatedly, the client just continually derping until it DCd. Followed the error message and added the acks.


I haven't committed this because as mentioned I have no clue about this network stuff lol, all that is needed is to add :

Code: Select all

OutOfOrderpackets[seq] = p->Copy();
SendOutOfOrderAck(seq);

In the (check<0) around line 304 and 343. Will commit when someone confirms this is ok, or they can just commit after doing so

[Jabantiz]

Nice find, will check into this today to try and confirm it.

And yes an ack (acknowledgement) is to confirm the packet was received, the server and client have to process packets in the same order or else the encryption gets screwed up and they won't be able to understand each other, so they will send the same packets over and over until it gets an ack.

[Jabantiz]

if (check < 0) is duplicate packets, server already received the packet once and should have already sent out the ack. I have a hard time getting this ping o'death on my local server as is so I say go ahead and commit it and lets see if John continues to get it.

[thefoof]

Committed

[John Adams]

I have a hard time getting this ping o'death on my local server as is so I say go ahead and commit it and lets see if John continues to get it.

This is pretty astonishing to me, since it happens on 4 EQ2Emu servers I run; DB Project, EQ2TC, JA Test server (through public login) and my localhost box. At first, I blamed my loopback config in my router, maybe because I was hosting all these servers myself... but that does not explain why players have it happen so frequently, too (you can tell by the logs).

If you are running Current eq2content (both Foof's database and scripts) and the current code (mine is usually x86 for faster compiles) then I am mind blown none of you see this besides me. I have nothing else special going on with this Windows 7 dev environment.

[Jabantiz]

Current content an x86 debug compile on a local login server, and I do see it, just not that often, maybe once or twice a week. Most of the time I am able to get onto the official and DB servers just fine too, though I do not often log onto those servers. Lets pray foof's fix will take care of the issue once and for all.

[John Adams]

If it does, I will mail him a case of his favorite beer.

[thefoof]

This is pretty astonishing to me, since it happens on 4 EQ2Emu servers I run; DB Project, EQ2TC, JA Test server (through public login) and my localhost box. At first, I blamed my loopback config in my router, maybe because I was hosting all these servers myself... but that does not explain why players have it happen so frequently, too (you can tell by the logs).

If you are running Current eq2content (both Foof's database and scripts) and the current code (mine is usually x86 for faster compiles) then I am mind blown none of you see this besides me. I have nothing else special going on with this Windows 7 dev environment.

Let me say I would get this, but WAY more often locally than connecting to EQ2TC/DB Proj, maybe it's due to zone startup, maybe it's just randomness from the client I don't really know. If the fix works I lean more towards client randomness.


But I spent a solid hour after I compiled this in locally and couldn't get it to happen again so it's reduced the severity if not gotten rid of it altogether hopefully, but we'll see over time

[John Adams]

I am very happy to report, my "90% consistent failure to connect" has all but vanished. I have been building the new ServerPack all morning, and not ONE connection attempt failed.

I think I'm going to tear up