UDP Plug

[Dyndrilliac]

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.

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.

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.

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

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.

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.

[o.OV]

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.

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.

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

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

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.

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.

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

[Grok]

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.

[o.OV]

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

[Spht]

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.

[o.OV]

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:

Code Select Expand


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


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

[Arta]

I think Spht's explanation is the most reasonable.

[o.OV]

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.

[Spht]

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.

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

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.

[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?

[Kp edit: fixed a formatting tag.]

[Dyndrilliac]

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:

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

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

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.

[Adron]

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.

[o.OV]

(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?

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

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

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

(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

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

[Spht]

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.

[o.OV]

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.