Ive been so used to 0 ms i have forgotten how to get a chat plug :X what was the code again? :o
Quote from: gosumoo on February 13, 2004, 09:05 PM
Ive been so used to 0 ms i have forgotten how to get a chat plug :X what was the code again? :o
Did you mean the lag plug?? If yes then, regardless of what you do during Packet 0x25, When you receive 0x51, You could do this:
SendPacket &H2D
InsertNonNTString "bnet"
SendPacket &H14
This should give you a lag plug, and if you want to not have a lag plug, just do:
SendPacket &H2D
InsertNonNTString "tenb"
SendPacket &H14
Hope this helps, feel free to flame on my post, *leans in the direction of NuLL*
What does 0x2d have to do with anything? And why would you send 0x14 containing the DWORD "tenb" (even though you sent it as a string)?
1. Do not send packet &H14
With 0ms lag, if you send &H25 only once.. Bnet will send &H0 every two minutes.. give or take a few seconds. ( I just reply with &H0 )
With Normal lag, Bnet will send &H25 every 25 seconds once you are in.. give or take. ( I reply with with &H0 )
EDIT: Not sure about number two.. but I don't think it's need.
Quote from: o.OV on February 14, 2004, 05:07 AM
1. Do not send packet &H14
2. Do not reply to Bnet's ping with a pong ( &H25 ) UNTIL you are actually logged in and in a Chat room.
With 0ms lag, if you send &H25 only once.. Bnet will send &H0 every two minutes.. give or take a fe seconds. ( I just reply with &H0 )
With Normal lag, Bnet will send &H25 every 25 seconds once you are in.. give or take. ( I reply with with &H0 )
AFAIK, 0x25 and the no-UDP plug are unrelated. Not responding to 0x25 will just get you a -1ms ping.
Edit: 6:15 am, expect typos.
Yea. I know.. that is why I editted. I am lagging so my post didn't edit immediately. Sorry for the delay.
If you disable udp, you get the plug.
If varPlug = 0 Then
'plug
pBuffer.InsertNonNTString "tenb"
pBuffer.SendPacket &H14
End If
This works for me.
0x25 only affects your ping, by sending the correct 0x14 packet, which should contain the dword "tenb", you will login fine, telling the server your client supports udp, and you can play games, however, since it is a tcp packet, you can ignore it, receive the little plug, and still be able to play games, but if you ignore or modify that packet, you will receive the flags responsible for the plug.
Edit: Wow, thats one hell of a run-on sentence, oh well, no time to fix! :P
QuoteWith 0ms lag, if you send &H25 only once.. Bnet will send &H0 every two minutes.. give or take a few seconds. ( I just reply with &H0 )
0x00 is sent approximately every two minutes when idle, and 0x25 doesn't interfere with it.
Quote from: LoRd[nK] on February 15, 2004, 02:10 PM
QuoteWith 0ms lag, if you send &H25 only once.. Bnet will send &H0 every two minutes.. give or take a few seconds. ( I just reply with &H0 )
0x00 is sent approximately every two minutes when idle, and 0x25 doesn't interfere with it.
To my knowledge you can't have 0ms if you don't send 0x25 after 0x1E/0x50.
What are you getting at?
You mean sending 0x25 again once you are in channel?
You must mean that because if you send it again before the login.. you will have regular lag..
Here is the scenario:
You connected sent 0x1E/0x50 and the SINGLE 0x25 to achieve 0ms lag.
You login fine and you are idle for 2 to 4 minutes.
During that time Bnet will not send 0x25 every 25 seconds if you connected "correctly" for 0ms lag BUT they will send 0x00 every 2 minutes.
Setup an IN_CHANNEL command to send 0x25 ONCE.
Once sent.. bnet will continue to send you 0x25 every 25 seconds AND 0x00 every two minutes.
Quote from: LoRd[nK] on February 15, 2004, 02:10 PM
0x00 is sent approximately every two minutes when idle, and 0x25 doesn't interfere with it.
Quote from: LoRd[nK] on February 19, 2004, 12:23 PM
Quote from: LoRd[nK] on February 15, 2004, 02:10 PM
0x00 is sent approximately every two minutes when idle, and 0x25 doesn't interfere with it.
Oh.
So you are trying to tell me it is quite alright to send 0x25
after login with 0ms lag even though it is absolutely not neccessary
and sending it will only cause bnet to continue sending you
0x25 every 25 seconds and 0x00 every 2 minutes.
Ok, Lord[nK] have it your way.
Any well made bot should seamlessly emulate the actual client, which is also why its a good idea to request the banner ad every ~15 seconds...
And also, 0x25 is sent S->C first, not C->S....Even if you dont echo it back, the server will still send 0x25....
Quote
battle.net does not send me 0x25 when I am in channel with 0ms lag
Ofcourse it does.
Quote
I have done my homework Lenny.
You've received an "F" on todays assignment, however you can makeup this assignment and turn it in no later than 2/23/04 for partial credit.
Quote from: o.OV on February 20, 2004, 10:26 PM
to get 0ms lag you don't actualy
wait for the server to send 0x25
you send it before and you don't respond
to their 0x25 packet
That is only upon logon...
Having any ping value on battle.net has no bearing on the 0x25 battle.net sends you in channel
That is correct, no matter what, your going to receive 0x25, and the only time it affects your ping is during login, if you ignore it, -1ms, if you delay it, you get a larger ping, if you send it before they do, 0ms, but once your logged in, you will receive it reguardless, and it will not affect anything.
If I may interject:
SID_NULL (0x00) has absolutely nothing to do with your latency. You can send it or not, Battle.net does not process it. Battle.net will send it to you regardless of whether you send it or don't. It's good practice to send it, because the game clients do.
SID_PING (0x25) is what effects your latency. I don't really care about getting 0/-1 ping, but if you do, I'm pretty sure that it works like this:
To get -1 ping, simply ignore all incoming ping messages from Battle.net;
To get 0 ping, send a ping message before you receive Battle.net's initial ping message. Most people accomplish this by sending SID_PING along with their initial logon packet, be it SID_AUTH_INFO (0x50), SID_CLIENTID (0x05), or SID_CLIENTID2 (0x1E).
The normal, best practice approach to handling ping requests is to immediately reply to any ping message you receive, with the value contained in the message. It's worth noting that this may not necessarily be a DWORD.
As far as I am aware, how you deal with the initial ping has absolutely no bearing on whether or not Battle.net sends you regular ping messages after logging on. It definitely has no bearing on whether or not you receive SID_NULL, as they are two completely different concepts - SID_NULL is designed to detect network failures, SID_PING is used to detect network latency.
Edit:
SID_PING and SID_NULL also have nothing at all to do with the chat plug, which indicates lack of UDP connectivity. By sending SID_UDPPINGRESPONSE (0x14), you inform Battle.net that you have received its UDP pings, and thus do not get the plug. You should send this value when you receive the UDP message PKT_CONNTEST2 (0x09) from Battle.net, but since the UDP ping value has thus far always been 'bnet', most people just send SID_UDPPINGRESPONSE along with their CD key message (whichever one it may be), or similar.
Quote from: Arta[vL] on February 21, 2004, 04:11 AM
To get -1 ping, simply ignore all incoming ping messages from Battle.net;
I'm not certain, but I believe you only need to ignore the first one. Also, if you ignore all ping requests and your client doesn't otherwise generate activity, the server may decide that your client process has become hung and will terminate your connection.
Quote from: Arta[vL] on February 21, 2004, 04:11 AM
As far as I am aware, how you deal with the initial ping has absolutely no bearing on whether or not Battle.net sends you regular ping messages after logging on. It definitely has no bearing on whether or not you receive SID_NULL, as they are two completely different concepts - SID_NULL is designed to detect network failures, SID_PING is used to detect network latency.
Yes, but as above, failure to generate any outbound traffic (responding to SID_PING counts as outbound traffic) will eventually get you dropped.
Quote from: Arta[vL] on February 21, 2004, 04:11 AM
SID_PING and SID_NULL also have nothing at all to do with the chat plug, which indicates lack of UDP connectivity.
Agreed. Since the real clients use the same location onscreen to display latency/UDP nonsupport, many people seem to associate the two. However, as you say, there is no technical relation.
Quote from: LoRd[nK] on February 20, 2004, 10:58 PM
Quote
battle.net does not send me 0x25 when I am in channel with 0ms lag
Ofcourse it does.
Quote
I have done my homework Lenny.
You've received an "F" on todays assignment, however you can makeup this assignment and turn it in no later than 2/23/04 for partial credit.
You obviously haven't tested my scenario yet buddy and you aren't my teacher.
When I said I have done my homework..
It is an expression similar to "I have done my research/tests".
Quote from: Lenny on February 20, 2004, 11:14 PM
Quote from: o.OV on February 20, 2004, 10:26 PM
to get 0ms lag you don't actualy
wait for the server to send 0x25
you send it before and you don't respond
to their 0x25 packet
That is only upon logon...
Having any ping value on battle.net has no bearing on the 0x25 battle.net sends you in channel
I didn't say 0x25 in channel had anything to do with ping value. However if you send it once with the 0x1E/0x50 then you reply to bnet's 0x25 then you will get a normal lag bar. You misunderstood me.
Quote from: MesiaH on February 21, 2004, 02:43 AM
That is correct, no matter what, your going to receive 0x25, and the only time it affects your ping is during login, if you ignore it, -1ms, if you delay it, you get a larger ping, if you send it before they do, 0ms, but once your logged in, you will receive it reguardless, and it will not affect anything.
Wrong.
I wouldn't be arguing this point if I didn't know what I was talking about.
Here is the log of the PacketIDs that come and go. TimeStamp included.
3:13:18 PM < ChrW$(1)
3:13:18 PM < 1E
3:13:18 PM < 6
3:13:19 PM < 25
3:13:19 PM > 5
3:13:19 PM > 1D
3:13:19 PM > 25
3:13:19 PM > 6
3:13:19 PM < 7
3:13:19 PM > 7
3:13:19 PM < 2D
3:13:20 PM > 2D
3:13:20 PM < 36
3:13:20 PM > 36
3:13:20 PM < 29
3:13:20 PM > 29
3:13:20 PM < 14
3:13:20 PM < A
3:13:20 PM < C
3:13:21 PM > A
3:13:21 PM > F
3:13:21 PM > F
3:16:14 PM > 0
3:18:16 PM > 0
3:20:17 PM > 0
3:22:18 PM > 0
3:24:19 PM > 0
3:26:35 PM > 0
3:28:21 PM > 0
Quote from: o.OV on February 21, 2004, 03:29 PM
Quote from: MesiaH on February 21, 2004, 02:43 AM
That is correct, no matter what, your going to receive 0x25, and the only time it affects your ping is during login, if you ignore it, -1ms, if you delay it, you get a larger ping, if you send it before they do, 0ms, but once your logged in, you will receive it reguardless, and it will not affect anything.
Wrong.
I wouldn't be arguing this point if I didn't know what I was talking about.
Here is the log of the PacketIDs that come and go. TimeStamp included.
3:13:18 PM < ChrW$(1)
3:13:18 PM < 1E
3:13:18 PM < 6
3:13:19 PM < 25
3:13:19 PM > 5
3:13:19 PM > 1D
3:13:19 PM > 25
3:13:19 PM > 6
3:13:19 PM < 7
3:13:19 PM > 7
3:13:19 PM < 2D
3:13:20 PM > 2D
3:13:20 PM < 36
3:13:20 PM > 36
3:13:20 PM < 29
3:13:20 PM > 29
3:13:20 PM < 14
3:13:20 PM < A
3:13:20 PM < C
3:13:21 PM > A
3:13:21 PM > F
3:13:21 PM > F
3:16:14 PM > 0
3:18:16 PM > 0
3:20:17 PM > 0
3:22:18 PM > 0
3:24:19 PM > 0
3:26:35 PM > 0
3:28:21 PM > 0
< and > appear to be backwards.
And as arta said, and what everyone here, except you, seem to agree apon:
Quote
If I may interject:
SID_NULL (0x00) has absolutely nothing to do with your latency. You can send it or not, Battle.net does not process it. Battle.net will send it to you regardless of whether you send it or don't. It's good practice to send it, because the game clients do.
SID_PING (0x25) is what effects your latency. I don't really care about getting 0/-1 ping, but if you do, I'm pretty sure that it works like this:
To get -1 ping, simply ignore all incoming ping messages from Battle.net;
To get 0 ping, send a ping message before you receive Battle.net's initial ping message. Most people accomplish this by sending SID_PING along with their initial logon packet, be it SID_AUTH_INFO (0x50), SID_CLIENTID (0x05), or SID_CLIENTID2 (0x1E).
The normal, best practice approach to handling ping requests is to immediately reply to any ping message you receive, with the value contained in the message. It's worth noting that this may not necessarily be a DWORD.
As far as I am aware, how you deal with the initial ping has absolutely no bearing on whether or not Battle.net sends you regular ping messages after logging on. It definitely has no bearing on whether or not you receive SID_NULL, as they are two completely different concepts - SID_NULL is designed to detect network failures, SID_PING is used to detect network latency.
Edit:
SID_PING and SID_NULL also have nothing at all to do with the chat plug, which indicates lack of UDP connectivity. By sending SID_UDPPINGRESPONSE (0x14), you inform Battle.net that you have received its UDP pings, and thus do not get the plug. You should send this value when you receive the UDP message PKT_CONNTEST2 (0x09) from Battle.net, but since the UDP ping value has thus far always been 'bnet', most people just send SID_UDPPINGRESPONSE along with their CD key message (whichever one it may be), or similar.
Lord[nK]..
I agree with Arta for most of what he has stated.
And as he himself has stated..
Quote
As far as I am aware, how you deal with the initial ping has absolutely no bearing on whether or not Battle.net sends you regular ping messages after logging on.
Even he does not entirely know.. As he said before.. He doesn't care for -1/0ms lag so I don't blame him for not knowing.
And the "<" and ">" aren't backwards.
"<" is going out as in "<< cout"
and vice versa.
Quote
battle.net does not send me 0x25
when I am in channel with 0ms lag
unless I send them 0x25 while in channel
Perhaps, you misunderstood me, I meant what Mesiah said....
Regardless of any ping you have, while in channel battle.net will still send you 0x25, whether you want to respond to it or not is your choice...
I believe we have all tested this....
Quote from: Kp on February 21, 2004, 11:44 AM
Quote from: Arta[vL] on February 21, 2004, 04:11 AM
As far as I am aware, how you deal with the initial ping has absolutely no bearing on whether or not Battle.net sends you regular ping messages after logging on. It definitely has no bearing on whether or not you receive SID_NULL, as they are two completely different concepts - SID_NULL is designed to detect network failures, SID_PING is used to detect network latency.
Yes, but as above, failure to generate any outbound traffic (responding to SID_PING counts as outbound traffic) will eventually get you dropped.
I disagree.
I have remained Logged In for over 45 minutes without sending ANYTHING to battle.net.
All I have recieved are 0x00 every 2 minutes or so.
Failure to reply to 0x25 will get the user disconnected from battle.net.(InChannel)
Quote from: Lenny on February 21, 2004, 04:07 PM
Quote
battle.net does not send me 0x25
when I am in channel with 0ms lag
unless I send them 0x25 while in channel
Perhaps, you misunderstood me, I meant what Mesiah said....
Regardless of any ping you have, while in channel battle.net will still send you 0x25, whether you want to respond to it or not is your choice...
I believe we have all tested this....
All tested with the same scenario I have laid down before you?
I doubt that.
I have posted my PacketID log as you can see.
I argue this point with confidence because I have my test results to back me up.
Quote from: o.OV on February 21, 2004, 03:54 PM
Lord[nK]..
I agree with Arta for most of what he has stated.
And as he himself has stated..
Quote
As far as I am aware, how you deal with the initial ping has absolutely no bearing on whether or not Battle.net sends you regular ping messages after logging on.
Even he does not entirely know.. As he said before.. He doesn't care for -1/0ms lag so I don't blame him for not knowing.
And the "<" and ">" aren't backwards.
"<" is going out as in "<< cout"
and vice versa.
> Outgoing
< Incomming
Quote from: LoRd[nK] on February 21, 2004, 04:20 PM
Quote from: o.OV on February 21, 2004, 03:54 PM
Lord[nK]..
I agree with Arta for most of what he has stated.
And as he himself has stated..
Quote
As far as I am aware, how you deal with the initial ping has absolutely no bearing on whether or not Battle.net sends you regular ping messages after logging on.
Even he does not entirely know.. As he said before.. He doesn't care for -1/0ms lag so I don't blame him for not knowing.
And the "<" and ">" aren't backwards.
"<" is going out as in "<< cout"
and vice versa.
> Outgoing
< Incomming
.. Ok, Lord[nK].
YOU WIN ~ ! :-*
Quote from: o.OV on February 21, 2004, 04:11 PM
Quote from: Kp on February 21, 2004, 11:44 AM
Quote from: Arta[vL] on February 21, 2004, 04:11 AM
As far as I am aware, how you deal with the initial ping has absolutely no bearing on whether or not Battle.net sends you regular ping messages after logging on. It definitely has no bearing on whether or not you receive SID_NULL, as they are two completely different concepts - SID_NULL is designed to detect network failures, SID_PING is used to detect network latency.
Yes, but as above, failure to generate any outbound traffic (responding to SID_PING counts as outbound traffic) will eventually get you dropped.
I disagree.
I have remained Logged In for over 45 minutes without sending ANYTHING to battle.net.
All I have recieved are 0x00 every 2 minutes or so.
Failure to reply to 0x25 will get the user disconnected from battle.net.(InChannel)
"I have remained Logged In for over 45 minutes without sending ANYTHING to battle.net."
is inconsistent with
"Failure to reply to 0x25 will get the user disconnected from battle.net.(InChannel)"
How did you stay on for 45 minutes?
Try it out guys, I just did... he's right.
Quote from: Soul Taker on February 21, 2004, 07:06 PM
Try it out guys, I just did... he's right.
At most, o.OV can be 1/2 right...Since he said this happens for 0x50 AND 0x1E
I have never tested with 0x1E, but for 0x50 this is not true....
So I also recommend o.OV try it with 0x50, to show that we are also right...
Edit: After looking at that post more carefully, I realized Soul Taker never specified what he tried. I assume he was referring to o.OV's belief that with 0ms ping battle.net will not send 0x25 in channel.
o.Ov, for future posts, use the edit button, or put all your information in the same post.
Also, Ping has nothing to do with UDP Plug, so why is it being discussed? Why is anything not related to the UDP Plug being discussed in a topic labeled "Chat Plug"?
For the sake of being on topic, I have tested each scenario mentioned - and found Arta to be correct, in all cases.
Quote from: Lenny on February 21, 2004, 05:44 PM
Quote from: o.OV on February 21, 2004, 04:11 PM
Quote from: Kp on February 21, 2004, 11:44 AM
Quote from: Arta[vL] on February 21, 2004, 04:11 AM
As far as I am aware, how you deal with the initial ping has absolutely no bearing on whether or not Battle.net sends you regular ping messages after logging on. It definitely has no bearing on whether or not you receive SID_NULL, as they are two completely different concepts - SID_NULL is designed to detect network failures, SID_PING is used to detect network latency.
Yes, but as above, failure to generate any outbound traffic (responding to SID_PING counts as outbound traffic) will eventually get you dropped.
I disagree.
I have remained Logged In for over 45 minutes without sending ANYTHING to battle.net.
All I have recieved are 0x00 every 2 minutes or so.
Failure to reply to 0x25 will get the user disconnected from battle.net.(InChannel)
"I have remained Logged In for over 45 minutes without sending ANYTHING to battle.net."
is inconsistent with
"Failure to reply to 0x25 will get the user disconnected from battle.net.(InChannel)"
How did you stay on for 45 minutes?
Yes !
Quote
"Failure to reply to 0x25 will get the user disconnected from battle.net"
In my case I never recieve 0x25 InChannel meaning there is nothing to reply to.
How is the connection kept alive if you don't reply to anything battle.net sends you?
As Arta said, failure to generate any outbound traffic will get you dropped...
Quote from: Lenny on February 21, 2004, 08:13 PM
Quote from: Soul Taker on February 21, 2004, 07:06 PM
Try it out guys, I just did... he's right.
At most, o.OV can be 1/2 right...Since he said this happens for 0x50 AND 0x1E
I have never tested with 0x1E, but for 0x50 this is not true....
So I also recommend o.OV try it with 0x50, to show that we are also right...
Edit: After looking at that post more carefully, I realized Soul Taker never specified what he tried. I assume he was referring to o.OV's belief that with 0ms ping battle.net will not send 0x25 in channel.
Heh. I'm not sure what you are doing differently..
but I get the same results as 0x1E.
2:48:13 AM < ChrW$(1)
2:48:13 AM < 50
2:48:13 AM < 25
2:48:14 AM > 25
2:48:14 AM > 50
2:48:14 AM < 51
2:48:14 AM > 51
2:48:14 AM < 14
2:48:14 AM < 2D
2:48:14 AM < 3A
2:48:15 AM > 2D
2:48:15 AM > 3A
2:48:15 AM < A
2:48:15 AM < C
2:48:15 AM > A
2:48:16 AM < 46
2:48:16 AM < C
2:48:16 AM > F
2:48:16 AM > F
2:48:16 AM > F
2:48:16 AM > 46
2:51:42 AM > 0
2:53:44 AM > 0
2:55:44 AM > 0
2:57:45 AM > 0
2:59:46 AM > 0
Quote from: Dyndrilliac on February 21, 2004, 08:43 PM
o.Ov, for future posts, use the edit button, or put all your information in the same post.
Also, Ping has nothing to do with UDP Plug, so why is it being discussed? Why is anything not related to the UDP Plug being discussed in a topic labeled "Chat Plug"?
For the sake of being on topic, I have tested each scenario mentioned - and found Arta to be correct, in all cases.
I think you are doing the scenarios wrong as well.
Because if you performed my scenario correctly
you wouldn't be recieving 0x25.
Try voiding out 0x25 completely
since in none of my scenarios will you ever reply to it.
And 0x25 should only be sent immediately after 0x1E/0x50.
I only use modify if I'm adding on to the reply to the same person.
And there is nothing wrong with going off topic.
It happens all the time
if the forum admin
feels it should be on a new thread..
I'm sure they would move it.
Maybe they will. I dunno.
Who cares as long as it works....
Quote from: Dyndrilliac on February 22, 2004, 10:26 AM
Who cares as long as it works....
Quote
For the sake of being on topic, I have tested each scenario mentioned - and found Arta to be correct, in all cases.
With that attitude my guess is..
You didn't test any of the scenarios.
And if you did..
you didn't put effort into trying to simulate my PacketID log.
Less checkups from battle.net means less bandwidth usage
and 56k users won't drop as easily if they are lagging like mad.
And don't give me that 56k users should die BS :)
I tried it the other night. If you send 0x25 with 0x50, to get 0 ms ping, you won't recieve 0x25 intermittently while in chat. I was expecting to prove him wrong but he's right.
Quote from: Lenny on February 22, 2004, 03:06 AM
How is the connection kept alive if you don't reply to anything battle.net sends you?
As Arta said, failure to generate any outbound traffic will get you dropped...
Kp said that NOT Arta.
And I just ran some tests on it..
the results were inconsistent.
I connected to battle.net with 0ms
disconnected my connection
(The first connection is still logged on despite the fact that I have disconnected)
acquired a new ip and reconnected to battle.net.
The first connection didn't drop on its own for about 2 minutes in my first test and 9 minutes on my second.
My guess is the 0x00 packets since that is the only traffic at all..
and its Incoming.
Quote
SID_NULL (0x00) has absolutely nothing to do with your latency. You can send it or not, Battle.net does not process it. Battle.net will send it to you regardless of whether you send it or don't. It's good practice to send it, because the game clients do.
Quote
SID_NULL is designed to detect network failures,
SID_PING is used to detect network latency.
And now is good time to share with the rest of bnet..
I am 56k and I can spoof 15/16ms lag.
It involves taking advantage of 0x00 to HELP spoof it.
Quote from: o.OV on February 22, 2004, 03:07 PM
It involves taking advantage of 0x00 to HELP spoof it.
You
what?HELP meaning /help? HELP is what? How do you use SID_NULL to change your latency?
What
are you on about?
Quote from: Arta[vL] on February 23, 2004, 03:01 PM
Quote from: o.OV on February 22, 2004, 03:07 PM
It involves taking advantage of 0x00 to HELP spoof it.
You what?
HELP meaning /help? HELP is what? How do you use SID_NULL to change your latency?
What are you on about?
It's not so useful but I did it just because I knew it could be done.
:)
I use 0x00 to slightly increase the time
it takes for the server to process 0x25.
How many Nulls you send will vary depending on your connection speed.
I have both DSL and 56k..
For 56k I normally ping at 232ms.
I use about 725 Nulls
For DSL I normally ping at 62ms.
I use about 347 Nulls
(For me, 348 or more won't get me ipbanned
but I won't get a reply from battle.net..
If I could I would send more but I'm not clear on why B.net won't respond..
Perhaps it was sent too fast/too much)
This is why I used the term HELP..
because 0x00 is being used to AFFECT the outcome.
The first time I ever got 15ms was by accident
and it did not involve using 0x00.
You're saying your sending 0x00 to Bnet in order to create more time for the server to process the packets leading upto your response with 0x025, thus spoofing your ping higher than it normally would be?
That seems silly and moronic, seeing as you can just let the client sit idle (using functions(depending on your language), which means you will never get IP banned with this because your not mass sending) to increase the amount of time in the gap from the time you send 0x25 - which again proves 0x00 has NO EFFECT on ping whatsoever no matter how or why you use it. Get over it. you're wrong.
Quote from: Dyndrilliac on February 23, 2004, 06:14 PM
You're saying your sending 0x00 to Bnet in order to create more time for the server to process the packets leading upto your response with 0x025, thus spoofing your ping higher than it normally would be?
That seems silly and moronic, seeing as you can just let the client sit idle (using functions(depending on your language), which means you will never get IP banned with this because your not mass sending) to increase the amount of time in the gap from the time you send 0x25 - which again proves 0x00 has NO EFFECT on ping whatsoever no matter how or why you use it. Get over it. you're wrong.
Did I even say I get ipbanned?
Why don't you try delaying the packet client side
while on 56k modem and see if you can get 15/16ms
while using 56k.
FYI, I have tested this already and I did try delaying it client side.
IT DOESN'T WORK!!
People like you don't seem to like testing things but instead..
you like to make critical statements
despite the fact that you lack knowledge on the matter.
And your theory doesn't disprove anything.
How do you explain the fact that I am a 56k user with 15/16ms lag?
You are saying 0x00 didn't play a vital role in it.
If anything you are proving that you are silly, moronic, and wrong.
You should really test your theories before replying again.
QuoteWhy don't you try delaying the packet client side
while on 56k modem and see if you can get 15/16ms
while using 56k.
Uhhh, you're contradicting yourself, buddy.
QuoteThis is why I used the term HELP..
because 0x00 is being used to AFFECT the outcome.
The first time I ever got 15ms was by accident
and it did not involve using 0x00.
Your miraculous low ping had nothing to dow ith your 0x00 method anyway, so that's completely irrelevant.
QuoteFYI, I have tested this already and I did try delaying it client side.
IT DOESN'T WORK!!
Yes it does. If you delay the time you send the packet, the connection to the server becomes idle, - spoofing your ping higher than it would normally.
I have done this many times before and got my ping as high as 50000 on T3. How do you expect the server to process a packet it hasn't recieved? Your ping becomes larger the longer it takes for Battle.net to recieve the ping related packets. That's why people that take forever to connect have huge pings, duh. The client side speed has everything to do with ping, the server side speed is relative to the clientside speed because a server cannot process a packet it hasnt recieved.
QuotePeople like you don't seem to like testing things but instead..
you like to make critical statements
despite the fact that you lack knowledge on the matter.
I guess were all just stupid dumbasses then, and you're the only one capable of doing it correctly seeing as how the majority of everyone here comes up with similar and comparable results whereas your's is different and it never occurred to you that maybe YOUR doing it wrong...
QuoteAnd your theory doesn't disprove anything.
How do you explain the fact that I am a 56k user with 15/16ms lag?
You are saying 0x00 didn't play a vital role in it.
If anything you are proving that you are silly, moronic, and wrong.
When in a debate, contradicting yourself is a bad idea.
QuoteThe first time I ever got 15ms was by accident
and it did not involve using 0x00.
You're basically saying you got your fancy 15ms on 56k, without using 0x00, but it is the reason you got 15ms. Are you dyslexic or something? That makes no sense whatsoever...These statements prove you got the lag without the packet - I'm right, you are wrong.
The sad part is you call me silly when you shot down your own arguments.
Quote
Quote
Why don't you try delaying the packet client side
while on 56k modem and see if you can get 15/16ms
while using 56k.
Uhhh, you're contradicting yourself, buddy.
Really? How so.
That was me challenging you to test your own theory buddy.
You severely misinterpreted me.
Quote
Quote
This is why I used the term HELP..
because 0x00 is being used to AFFECT the outcome.
The first time I ever got 15ms was by accident
and it did not involve using 0x00.
Your miraculous low ping had nothing to dow ith your 0x00 method anyway, so that's completely irrelevant.
Heh. And how do you know 0x00 had nothing to do with it?
It's not like you ever tried it for yourself.
So you think it's a miracle that I can get 15/16ms?
That's alot of miracles.
How do you explain the "miracles" then "Genius"?
You come up with a MORE EFFICIENT and WORKING method without 0x00 on 56k
and I'll apologize for doubting you.
Quote
Quote
FYI, I have tested this already and I did try delaying it client side.
IT DOESN'T WORK!!
Yes it does. If you delay the time you send the packet, the connection to the server becomes idle, - spoofing your ping higher than it would normally.
I have done this many times before and got my ping as high as 50000 on T3. How do you expect the server to process a packet it hasn't recieved? Your ping becomes larger the longer it takes for Battle.net to recieve the ping related packets. That's why people that take forever to connect have huge pings, duh. The client side speed has everything to do with ping, the server side speed is relative to the clientside speed because a server cannot process a packet it hasnt recieved.
LOL Whoa guy. You should take your head out of the clouds every once in a while.
The objective is to get a lower latency then normal not higher.
Getting a high latency is way too easy and I have reached at least 900000.
My normal without using 0x00 is 230/250
My spoof using 0x00 is 15/16
Quote
Quote
People like you don't seem to like testing things but instead..
you like to make critical statements
despite the fact that you lack knowledge on the matter.
I guess were all just stupid dumbasses then, and you're the only one capable of doing it correctly seeing as how the majority of everyone here comes up with similar and comparable results whereas your's is different and it never occurred to you that maybe YOUR doing it wrong...
Dumbasses? If you say so. I didn't say that. :)
I wasn't the only one who managed to perform my scenario CORRECTLY.
You should read the earlier posts more carefully.
To my knowledge.. Soul Taker was the ONLY one to test..
Quote
Quote
And your theory doesn't disprove anything.
How do you explain the fact that I am a 56k user with 15/16ms lag?
You are saying 0x00 didn't play a vital role in it.
If anything you are proving that you are silly, moronic, and wrong.
When in a debate, contradicting yourself is a bad idea.
Reminder, you were trying to DISPROVE my "theory"/statement.
You failed.
You couldn't even give an ALTERNATE EXPLANATION as to why my method works.
And the insults I gave you are echos of the insults you gave me.
Do you understand what it means to contradict?
Again I was asking you for an explanation of how I got 15/16ms on a 56k modem.
Quote
Quote
The first time I ever got 15ms was by accident
and it did not involve using 0x00.
You're basically saying you got your fancy 15ms on 56k, without using 0x00, but it is the reason you got 15ms. Are you dyslexic or something? That makes no sense whatsoever...These statements prove you got the lag without the packet - I'm right, you are wrong.
The sad part is you call me silly when you shot down your own arguments.
I said the FIRST TIME I ever got it.. was by accident.
I was lagging maliciously. People don't normally LAG like MAD on a normal basis..
Or they wouldn't even logon at all as it would be a waste of their time.
And even if I did LAG on purpose I was NOT ABLE TO REPRODUCE THE RESULTS again without adding new code.
Again I challenge you to use a 56k modem and get 15/16ms lag without 0x00. :P
Let's see if you can accidentally get 15/16ms lag using 56k.
I dare you take up that challenge.
You aren't gonna wuss out on the challenge now are you? ^^ COME ON
Add-on:
If you aren't gonna take up my challenge then please stop posting on this thread..
If you are gonna hate me choose a different thread..
I think this thread should be locked because I'm getting sick of arguing over this >_<
Good god stop the insanity. You guys are arguing about nothing.
Latency and bandwidth are two distinct measurements.
Latency is how fast you can get there with a given packet size.
Bandwidth is how much you can get there over a given timeframe.
Quote from: Grok on February 24, 2004, 12:30 AM
Good god stop the insanity. You guys are arguing about nothing.
Latency and bandwidth are two distinct measurements.
Latency is how fast you can get there with a given packet size.
Bandwidth is how much you can get there over a given timeframe.
heh :)
Sorry, Grok.
It's a useless feature
to be able to spoof a lag at 15/16ms lag.
It's just something interesting was trying to share with everyone else..
Quote from: o.OV on February 24, 2004, 12:42 AM
Quote from: Grok on February 24, 2004, 12:30 AM
Good god stop the insanity. You guys are arguing about nothing.
Latency and bandwidth are two distinct measurements.
Latency is how fast you can get there with a given packet size.
Bandwidth is how much you can get there over a given timeframe.
heh :)
Sorry, Grok.
It's a useless feature
to be able to spoof a lag at 15/16ms lag.
It's just something interesting was trying to share with everyone else..
I think I know what you're trying to debate. The reason why you're getting that ping is you're sending early mass SID_NULL's followed by SID_PING (before you get any SID_PING from the server). All this is doing is delaying the upload of SID_PING to the server because your connection has to send all the SID_NULL's first, so the server gets SID_PING a little later than it would if you sent it immediately early, which is getting you a little more than zero ping time. I think Dyndrilliac is trying to tell you that this is unnecessary, and you could create the same effect if you just delay sending of SID_PING a little (by using a timer or something), instead of delaying the upload by spamming server. This would be a more simpler and safer method.
Quote from: Spht on February 24, 2004, 01:05 AM
Quote from: o.OV on February 24, 2004, 12:42 AM
Quote from: Grok on February 24, 2004, 12:30 AM
Good god stop the insanity. You guys are arguing about nothing.
Latency and bandwidth are two distinct measurements.
Latency is how fast you can get there with a given packet size.
Bandwidth is how much you can get there over a given timeframe.
heh :)
Sorry, Grok.
It's a useless feature
to be able to spoof a lag at 15/16ms lag.
It's just something interesting was trying to share with everyone else..
I think I know what you're trying to debate. The reason why you're getting that ping is you're sending early mass SID_NULL's followed by SID_PING (before you get any SID_PING from the server). All this is doing is delaying the upload of SID_PING to the server because your connection has to send all the SID_NULL's first, so the server gets SID_PING a little later than it would if you sent it immediately early, which is getting you a little more than zero ping time. I think Dyndrilliac is trying to tell you that this is unnecessary, and you could create the same effect if you just delay sending of SID_PING a little (by using a timer or something), instead of delaying the upload by spamming server. This would be a more simpler and safer method.
I have already tried using alternate methods of delaying on the client side..
DoEvents,
Sleep,
SetTimer,
Even some calls to a Dummy Function/Sub.
None of those work.
Add-On:
Public Sub send0x1E()
'0x1E(0x06)/0x50 SENT
'DoEvents ' 300MS +
'Sleep 0 ' 0MS
'Sleep 10000 ' 0MS
'SetTimer Form1.hwnd, 6699, 0, AddressOf send0x25 ' 300MS +
'For X = 0 To 725 'for 56k
'For X = 0 To 347 'for dsl
' pBuffer.SendPackeT &H0
'Next X
'pBuffer.InsertDWORD &H0
'pBuffer.SendPacket &H25
End Sub
Public Sub send0x25()
pBuffer.InsertDWORD &H0
pBuffer.SendPacket &H25
KillTimer Form1.hWnd, 6699
End Sub
Quote
For 56k I normally ping at 232ms.
I use about 725 Nulls
For DSL I normally ping at 62ms.
I use about 347 Nulls
(For me, 348 or more won't get me ipbanned
but I won't get a reply from battle.net..
If I could I would send more but I'm not clear on why B.net won't respond..
Perhaps it was sent too fast/too much)
Also..
Can someone explain why it takes less null packets
for my DSL connection to get 15/16ms
While it takes more for 56k
I think Spht's explanation is the most reasonable.
Does uploading the bytes really make that much of a difference?
The total number of bytes sent is less then 3kb for 56k.
For DSL I send less then 1.5 kb.
4 bytes per null and 8 bytes for PING
I made an assumption that battle.net
has to take time to parse the incoming data
just as battle.net bots do..
That was what the general principle behind the method I used..
or so I thought.. :\
mm.. Ok..
The lower MTU between two computers
determines the max number of bytes in any transmission.
Is it one packet per transmission?
If so then Spht's explanation would fit in very well..
Or can a single transmission contain multiple packets?
I made an assumption that this was the case..
Does the server wait for the transmission to end before processing?
Or does it begin processing immediately upon arrival of the first byte.
Would make sense for it to wait for end of transmission.
I took some time to look up on the subject
but the pages I visited didn't mention it
or I just didn't notice it.
Can you end this please? Reading my post and having a little imagination will let you know why you need less SID_NULLs to send on a faster connection.
Quote from: o.OV on February 24, 2004, 06:48 AM
I made an assumption that battle.net
has to take time to parse the incoming data
just as battle.net bots do..
No, your mass nulls aren't causing the server to slow down and take longer to process your SID_PING. If 200 four-byte packets to the server from one user caused it to slow down, I think I'd have a lot of trouble managing thousands of connections...
Quote from: o.OV on February 24, 2004, 06:48 AM
Does uploading the bytes really make that much of a difference?
The total number of bytes sent is less then 3kb for 56k.
For DSL I send less then 1.5 kb.
4 bytes per null and 8 bytes for PING
You have to send more SID_NULLs before SID_PING on your DSL simply because upload would normally be faster on DSL than it would on dial-up (56kbps) -- I thought this would be common sense?
As I've already explained, your sending SID_NULLs are simply delaying the time your connection gets to send the SID_PING, because it has to upload all the SID_NULLs first, and this upload will be faster on DSL, which is why you have to send more of them on DSL to create the same effect.
A high-resolution timer can be used to create the same effect. You will probably need to manually delay the SID_PING by about 0.00025 seconds on DSL.
He claims that he needs more on 56k than he does on DSL, not less. Or perhaps he got that the wrong way round?
[Kp edit: fixed a formatting tag.]
Quote
Quote
Quote
This is why I used the term HELP..
because 0x00 is being used to AFFECT the outcome.
The first time I ever got 15ms was by accident
and it did not involve using 0x00.
Your miraculous low ping had nothing to dow ith your 0x00 method anyway, so that's completely irrelevant.
Heh. And how do you know 0x00 had nothing to do with it?
It's not like you ever tried it for yourself.
Ok, let me spell this out for you.
I KNOW for a fact that your ping had no relationship with 0x00(No direct requirement of presence for desired results to take effect), because you said outright:
QuoteThe first time I ever got 15ms was by accident
and it did not involve using 0x00.
Therefore, one can easily assume that you CAN get the same results whether you use your ghetto packet spamming method or not!! THIS IS THE POINT IM TRYING TO MAKE!! YOUR METHODS WHETHER IT WORKS OR NOT IS NOT THE ONLY FREAKING WAY!! Maybe if you got your head out of your ass and thought for a second you would see that to get the same results twice with different methods, this argument would have been over ages ago, but no, you have to be such a fanatic zealous moron that you can't see past your own discovery.
There are probably several ways of doing this and more. The entire reason I cited a n instance of HIGH ping, is because you use the same method, only at a different time.
QuoteI wasn't the only one who managed to perform my scenario CORRECTLY.
You should read the earlier posts more carefully.
To my knowledge.. Soul Taker was the ONLY one to test..
Or maybe because hes the only other person who got comparable results, your going to say I didn't put forth any effort because of the fact I knew I was right before I tried? Sad that you have to blame the fact your results were not effectively reproduced on my attitude, when infact I have tested similar instances many times.
Quote from: Dyndrilliac on February 24, 2004, 02:47 PM
Therefore, one can easily assume that you CAN get the same results whether you use your ghetto packet spamming method or not!! THIS IS THE POINT IM TRYING TO MAKE!! YOUR METHODS WHETHER IT WORKS OR NOT IS NOT THE ONLY FREAKING WAY!!
Maybe what you're failing to realize is that the Nagle algorithm will interfere with your trying to send a small packet after a given short delay and either cause the whole thing to be sent at once, or delay it a RTT, which for a 56k modem is much higher than 15 ms? None of you have mentioned turning off Nagle.
Quote
(spht)
You have to send more SID_NULLs before SID_PING on your DSL simply because upload would normally be faster on DSL than it would on dial-up (56kbps) -- I thought this would be common sense?
Quote
(arta)
He claims that he needs more on 56k than he does on DSL, not less. Or perhaps he got that the wrong way round?
Yup =\
Spht misinterpreted me.
Quote
(spht)
A high-resolution timer can be used to create the same effect. You will probably need to manually delay the SID_PING by about 0.00025 seconds on DSL.
I'll look into it ..
Quote
(dyndrilliac)
There are probably several ways of doing this and more.
.. I already asked you to come up with a way of your own ..
I said I will apologize for doubting you if you do manage.
Quote
(adron)
Maybe what you're failing to realize is that the Nagle algorithm will interfere with your trying to send a small packet after a given short delay and either cause the whole thing to be sent at once, or delay it a RTT, which for a 56k modem is much higher than 15 ms? None of you have mentioned turning off Nagle.
Heh. I never heard of a Nagle algorithm before. I'll look into that as well.
Add-On:
this google search (http://www.google.com/search?q=cache:tg3-NRgQvOsJ:tangentsoft.net/wskfaq/intermediate.html+nagle+algorithm&hl=en&ie=UTF-8)
Link doesn't show correctly on the forum.. Copy and paste it.
The nagle algorithm answered quite a few questions I had ^^
And it gave me an idea of how/why my method works.. +1 Adron
Using new found knowledge on the nagle algorithm.
I decreased the number of nulls I sent so my string
of packets would fit into a single frame .
So instead of sending 725 nulls I decreased it to 347.
And according to the nagle algorithm..
The server would recieve the frame which is about 1500 bytes.
Meaning they begin processing only upon recieving the WHOLE frame
which in turn contains the multiple packets.
Did I get that wrong?
[Kp edit: fixed URL tag, renamed it to stop tampering with spacing.]
Quote from: o.OV on February 24, 2004, 06:25 PM
Yup =\
Spht misinterpreted me.
I assume you made a mistake, since having to send more SID_NULLs on dial-up than on DSL doesn't make much sense.
Quote from: Spht on February 24, 2004, 06:52 PM
Quote from: o.OV on February 24, 2004, 06:25 PM
Yup =\
Spht misinterpreted me.
I assume you made a mistake, since having to send more SID_NULLs on dial-up than on DSL doesn't make much sense.
Yeah.. I know it's strange.. lol
Add-On:
With knowledge of the Nagle Algorithm.
Sending 725 nulls at the same time caused my string of packets
to split into two different frames.
Which WAS NOT REQUIRED
the nagle algorithm explained that.
You were right to think it didn't make much sense.
It didn't make much sense to me either when I first came across it.
Quote from: Adron on February 24, 2004, 03:49 PM
Quote from: Dyndrilliac on February 24, 2004, 02:47 PM
Therefore, one can easily assume that you CAN get the same results whether you use your ghetto packet spamming method or not!! THIS IS THE POINT IM TRYING TO MAKE!! YOUR METHODS WHETHER IT WORKS OR NOT IS NOT THE ONLY FREAKING WAY!!
Maybe what you're failing to realize is that the Nagle algorithm will interfere with your trying to send a small packet after a given short delay and either cause the whole thing to be sent at once, or delay it a RTT, which for a 56k modem is much higher than 15 ms? None of you have mentioned turning off Nagle.
I turn it off (and so do clients) when sending ping replies.