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.

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?

[quote author=Hdx link=topic=17887.msg182132#msg182132 date=1238926403]
unless you have asynchronous packet handling {like the client}
[/quote]

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"

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

[quote author=PunK link=topic=17887.msg182129#msg182129 date=1238915664]
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.
[/quote]

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

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]
Connection sequence completed in 234ms.
Logged in with a ping of 31ms.
[/code]

[code]
Connection sequence completed in 234ms.
Logged in with a ping of 109ms.
[/code]

Bleh...

[quote author=Warrior link=topic=17887.msg182143#msg182143 date=1238975405]
[quote author=PunK link=topic=17887.msg182129#msg182129 date=1238915664]
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.
[/quote]

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

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.

Okay, then when should I respond to the packet?

[quote author=brew link=topic=17887.msg182204#msg182204 date=1239131373]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.[/quote]Last time i was working on a bot teh 0x25 packet came AFTER 0x50 But in all honesty it really dosent matter
[quote author=PunK link=topic=17887.msg182208#msg182208 date=1239135699]Okay, then when should I respond to the packet?[/quote] 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}

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...

[quote author=Hdx link=topic=17887.msg182209#msg182209 date=1239138155]
Last time i was working on a bot teh 0x25 packet came AFTER 0x50 But in all honesty it really dosent matter
[/quote]
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 author=Hdx link=topic=17887.msg182209#msg182209 date=1239138155]
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}
[/quote]
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.

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.

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.

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?

[quote author=chyea link=topic=17887.msg182217#msg182217 date=1239147270]
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?
[/quote]

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.

[quote author=PunK link=topic=17887.msg182218#msg182218 date=1239150977]
[quote author=chyea link=topic=17887.msg182217#msg182217 date=1239147270]
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?
[/quote]

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.
[/quote]

Not responding to 0x25 gives you a -1ms ping.

Also, last time I had troubles with high pings using local hashing was because my computer wasn't fast enough so it would take ages to build the 0x51 response thus giving me a high ping.
My 2 cents.