Hello,

Tested the following:

Random UDP Sizes 0 to 65000.

Rapid packets after each other.

Windows XP x64 and Windows XP 32 bit.

Program seems to work normally.

Sender and receiver more or less report the same size as well as ethereal.

It seems windows does not allow sending many random udp sizes right after
each other ?

Or could it be some kind of strange threading bug ?

Very strange.

When sending fixed size large udp packets ip fragmentation does work and
large udp packets get through.

But random udp sizes not ??????? Very very very very very strange ?!

(Only little packets arrive huh ?)

Bye,
Skybuck.

On Oct 16, 9:16 am, "Skybuck Flying" <s...@hotmail.com> wrote:
> Hello,
>
> Tested the following:
>
> Random UDP Sizes 0 to 65000.
>
> Rapid packets after each other.
>
> Windows XP x64 and Windows XP 32 bit.
>
> Program seems to work normally.
>
> Sender and receiver more or less report the same size as well as ethereal.
>
> It seems windows does not allow sending many random udp sizes right after
> each other ?
>
> Or could it be some kind of strange threading bug ?
>
> Very strange.
>
> When sending fixed size large udp packets ip fragmentation does work and
> large udp packets get through.
>
> But random udp sizes not ??????? Very very very very very strange ?!
>
> (Only little packets arrive huh ?)


No such issues exist, although you may be running out of buffers on
either or both sides. The default behavior of basically all TCP/IP
stacks is to discard UDP packets when out of space.

The default buffer allocated by Windows to a UDP socket is 8K (which
is smaller than on many system), which would correspond to five 1400
bytes packets plus a bit. Try increasing it with setsockopt()/
SO_RCVBUF.

Yeah I dug up my old c/cpp code for winsock and converted it to winsock 2.

Sending random udp sizes there does not create any bugs.

So it must be some kind of weird bug in my delphi application which uses
threads and dynamically loads the library.

Driving me nuts.

But I am gonna find it hopefully

Bye,
Skybuck

Ok,

It seems to be some kind of timing bug.

Could be overflow or maybe it's a bug in QueryPerformanceCounter.

For now I'll assume it's a bug in my timing code.

Still how a timing bug leads to little packets confuses me ?

It seems impossible.

Maybe it's an operating system bug after all, not sure though

Very strange.

More investigation will need to be done

Bye,
Skybuck.

Oh, now I understand !

It's an algorithm bug !

Kinda funny.

The data size is randomized.

And the speed limit is checked to see if bytes are available.

If not then a new data size is randomized.

So big data sizes never make it... because the thread runs so fast... the
bucket didn't have time to get full for a larger packet.

So that's why only smaller packets get through..

Hehe !

So algorithm has to change a little bit.

Initialize a random data size or so... keep trying to reserve the bytes from
the speed limit, when it's allowed to send... try to send it... and then it
doesn't matter if it was sent or not... because it passed the speed limit...
so then it's ok to initialize a new random data size.

This prevents illegal data size from holding things up as well... since a
new one would be generated

Bye,
Skybuck.