Bad ping

PunK · April 05, 2009, 02:14 AM

I'm not sure if it's the way I am handling BNCS but it seems when I local hash, it logs in with a bad ping. I usually get 31ms on client and when I use my bot, I am usually pinging around 150-300ms. Not that it effects me in anyway, but I would like to see if there is a way to fix this.

I've noticed the longer it takes to build 0x51, the higher your ping will be. So maybe it's my computer? I'm running a 3.2ghz P4 hyper threaded.. so idk what could be causing the problem. I've used local hashing on bots like stealth and haven't ever had this issue.

Hdx · April 05, 2009, 05:13 AM

Well usually Bnet sends you 0x25 along with 0x50 {after it but taked onto the same tcp/ip packet}
So whould it not make sense that any delay between receiving and sending it would cause a high ping, cuz thats well.. what that ping IS.

unless you have asynchronous packet handling {like the client}, or a priority based handler, you'll just have to deal with it.
But, its just your ping, who gives a fuck?

brew · April 05, 2009, 07:02 AM

Quote from: Hdx on April 05, 2009, 05:13 AM
unless you have asynchronous packet handling {like the client}

Really....
Doesn't seem that way to me, you're just plain wrong.
check for yourself. open it up in IDA and search for "ServerThreadProc"

Mystical · April 05, 2009, 08:19 AM

Have you tried letting someone else login your bot with hash to see if they have the same problem?

Warrior · April 05, 2009, 06:50 PM

Quote from: PunK on April 05, 2009, 02:14 AM
I'm not sure if it's the way I am handling BNCS but it seems when I local hash, it logs in with a bad ping. I usually get 31ms on client and when I use my bot, I am usually pinging around 150-300ms. Not that it effects me in anyway, but I would like to see if there is a way to fix this.

I've noticed the longer it takes to build 0x51, the higher your ping will be. So maybe it's my computer? I'm running a 3.2ghz P4 hyper threaded.. so idk what could be causing the problem. I've used local hashing on bots like stealth and haven't ever had this issue.

Hdx is right, it most likely has to do with Asyncronous vs Syncronous responses to packets.

PunK · April 07, 2009, 01:58 AM

I think I understand what you guys are saying..

Now, for kicks and giggles... I decided to record the speed for the login sequence. I started at 0x50 until I received 0x0A.

Code Select


Connection sequence completed in 234ms.
Logged in with a ping of 31ms.

Code Select


Connection sequence completed in 234ms.
Logged in with a ping of 109ms.

Bleh...

brew · April 07, 2009, 02:09 PM

Quote from: Warrior on April 05, 2009, 06:50 PM
Quote from: PunK on April 05, 2009, 02:14 AM
I'm not sure if it's the way I am handling BNCS but it seems when I local hash, it logs in with a bad ping. I usually get 31ms on client and when I use my bot, I am usually pinging around 150-300ms. Not that it effects me in anyway, but I would like to see if there is a way to fix this.

I've noticed the longer it takes to build 0x51, the higher your ping will be. So maybe it's my computer? I'm running a 3.2ghz P4 hyper threaded.. so idk what could be causing the problem. I've used local hashing on bots like stealth and haven't ever had this issue.

Hdx is right, it most likely has to do with Asyncronous vs Syncronous responses to packets.

No. It has to do with the fact the 0x25 is sent from the server before the 0x50 packet is. They are handled in order.

PunK · April 07, 2009, 03:21 PM

Okay, then when should I respond to the packet?

Hdx · April 07, 2009, 04:02 PM

Quote from: brew on April 07, 2009, 02:09 PMNo. It has to do with the fact the 0x25 is sent from the server before the 0x50 packet is. They are handled in order.

Last time i was working on a bot teh 0x25 packet came AFTER 0x50 But in all honesty it really dosent matter

Quote from: PunK on April 07, 2009, 03:21 PMOkay, then when should I respond to the packet?

As soon as you get it. One of teh other problems you could be running into is the nigel algo isnt actually sending the 0x25 packet ujntill you push out another packet, disable it on your socket, {google}

Ribose · April 07, 2009, 04:09 PM

Immediately upon seeing it. I have always gotten it before 0x50, but I don't recall it being the same for the legacy logon system...

brew · April 07, 2009, 05:21 PM

Quote from: Hdx on April 07, 2009, 04:02 PM
Last time i was working on a bot teh 0x25 packet came AFTER 0x50 But in all honesty it really dosent matter

That's interesting, every single battle.net logon i've worked with is the exact opposite. And in all honesty it does matter. It's especially important in this case.

Quote from: Hdx on April 07, 2009, 04:02 PM
One of teh other problems you could be running into is the nigel algo isnt actually sending the 0x25 packet ujntill you push out another packet, disable it on your socket, {google}

Don't know how he can possibly google it when you've grossly mispelled the only search term he would have to work with...
Here you are: http://msdn.microsoft.com/en-us/library/ms740476(VS.85).aspx, TCP_NODELAY
I doubt this is the problem though.

I fail to see the relevance in Ribose's post.

MyndFyre · April 07, 2009, 05:57 PM

I've seen it come in both orders - 0x25 either preceding or following 0x50. And I've also observed that it doesn't matter which the client answers first. I've seen the same behavior from the official client (getting pings in the yellow on Starcraft is ridiculously unlikely on a connection where I get 2MiB/s sustained downloads)

Whether the client handles the packet out-of-order or asynchronously is only important in passing in this case; it seems the official client handles packets synchronously (at least for Starcraft) which would explain the behavior I just described.

Asynchronously handling the packet would only yield improved response times on multi-core processors, which were not common until the last couple of years.

PunK · April 07, 2009, 06:05 PM

Alright, in my dataarrival event, I'm not even passing 0x25 to my debuffer but I am splitting 0x50 and parsing that. So before anything is done, 0x25 is sent back to battle.net before 0x50 even reaches the debuffer. Pings are a little lower but still hitting around 125-150 and random 31ms.

I know this isn't much to worry about, but it's something I would like to fix rather then ignore. Also, another thing, I tested BNLS rather then local hashing and I never go over 47ms.

@Hdx: I don't think this would be my problem. Used analogx to see my outgoing data and 0x25 is indeed being sent without 0x50.

bulletproof tiger · April 07, 2009, 06:34 PM

It has been a long time since I've worked with battle.net, but wasn't there a packet that was sent to the client and the client responded to, that determined the user's latency? It'd be logical to respond to this as fast as possible to obtain the fastest latency possible. If I recall you could ignore this packet completely and that'd result in the -1 latency.

Like I said, it has been awhile. Maybe it's no longer this way?

PunK · April 07, 2009, 07:36 PM

Quote from: chyea on April 07, 2009, 06:34 PM
It has been a long time since I've worked with battle.net, but wasn't there a packet that was sent to the client and the client responded to, that determined the user's latency? It'd be logical to respond to this as fast as possible to obtain the fastest latency possible. If I recall you could ignore this packet completely and that'd result in the -1 latency.

Like I said, it has been awhile. Maybe it's no longer this way?

Not responding causes 0 ping I believe. But I am already responding to the packet as fast as my connection can. It's not even going through my parser; it's going straight from arrival back to the socket.

edit--

'Okay, so I guess it comes down to 0x51. I am responding to 0x25 as soon as I get it, so that's not the problem. But... when i slow down the build of 0x51 (if I pause it before I send it) I get horrible ping time. I'm at a complete loss right now... Blah.