Please help me with my lost UDP packets

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm new to the Compact Framework and C# but have been programming for
years, but not on small devices.

I have written a program running on Dell Axim that receives UDP packets.
that was converted from java using the tool provided by Microsoft. It
creates a TextBox to display messages (like "packet received" etc) and a
button. When the button is pressed the program listens for UDP packets
on port 51800.

On my desktop PC I then run a program that creates packets and sends
them to the proper IP address/port. Early in my learning process I
learned that I needed to disconnect the Axim from the cradle and use the
wireless network for receiving network traffic. I *DO* receive some of
the UDP packets, so my problem is not that I can't receive any data ---
my problem is that delivery seems unreliable even by UDP standards.

Out of 100 packets (each 10 bytes) sent (with a delay of 500 or 1000 ms
between packets) my program receives 10-12 of them. I also tried 256
byte packets and 1024 with similar disappointing results.

Is this normal on these little devices? Am I expecting too much? I
know that UDP is not guaranteed but this seems so bad that I can only
assume my program is flawed.

I can provide more code if needed. A UdpClient is used to receive the
data. Here's the receive method if that helps.

THANKS!

public static void Receive(System.Net.Sockets.UdpClient tempClient,
out PacketSupport packet)
{
System.Net.IPEndPoint remoteIpEndPoint =
new System.Net.IPEndPoint(System.Net.IPAddress.Any, 0);

PacketSupport tempPacket;
try
{
byte[] data_in = tempClient.Receive(ref remoteIpEndPoint);
tempPacket = new PacketSupport(data_in, data_in.Length);
tempPacket.IPEndPoint = remoteIpEndPoint;
}
catch ( System.Exception e )
{
throw new System.Exception(e.Message);
}
packet = tempPacket;
}
 
How are you deciding how many of the packets were received? Counting them
in the code that calls UdpClient.Receive()? You aren't doing that in the
user interface thread, right?

Paul T.
 
@ *SPAM* yahoo_com said:
I'm new to the Compact Framework and C# but have been programming for
years, but not on small devices.

I have written a program running on Dell Axim that receives UDP packets.
that was converted from java using the tool provided by Microsoft. It
creates a TextBox to display messages (like "packet received" etc) and a
button. When the button is pressed the program listens for UDP packets
on port 51800.

On my desktop PC I then run a program that creates packets and sends
them to the proper IP address/port. Early in my learning process I
learned that I needed to disconnect the Axim from the cradle and use the
wireless network for receiving network traffic. I *DO* receive some of
the UDP packets, so my problem is not that I can't receive any data ---
my problem is that delivery seems unreliable even by UDP standards.

Out of 100 packets (each 10 bytes) sent (with a delay of 500 or 1000 ms
between packets) my program receives 10-12 of them. I also tried 256
byte packets and 1024 with similar disappointing results.

Is this normal on these little devices? Am I expecting too much? I
know that UDP is not guaranteed but this seems so bad that I can only
assume my program is flawed.

I can provide more code if needed. A UdpClient is used to receive the
data. Here's the receive method if that helps.

THANKS!

public static void Receive(System.Net.Sockets.UdpClient tempClient,
out PacketSupport packet)
{
System.Net.IPEndPoint remoteIpEndPoint =
new System.Net.IPEndPoint(System.Net.IPAddress.Any, 0);

PacketSupport tempPacket;
try
{
byte[] data_in = tempClient.Receive(ref remoteIpEndPoint);
tempPacket = new PacketSupport(data_in, data_in.Length);
tempPacket.IPEndPoint = remoteIpEndPoint;
}
catch ( System.Exception e )
{
throw new System.Exception(e.Message);
}
packet = tempPacket;
}
Click to expand...

In general, if you are looking towards using UDP and packet loss is
unacceptable you have two solutions.

1) Build a "smarter" protocol on top of UDP which implements sequence
numbers, resends, acks, etc..
2) Switch to TCP which already has sequence numbers, resends, acks, etc...

Most people would choose #2 and be on their merry way. Plain old UDP is not
reliable. It really depends on the networks, routers, etc... I wouldn't
waste much time on this issue. It is the nature of the beast. The only
feasible situation for using plain old UDP is in a video game or something
like that where speed is more important than data integrity or where data
integrity is not important at all.
 
Ummmmm maybe. Sounds like I'm breaking the rules. In my Form.cs file I
create a thread when a button is clicked, like this:

private void button1_Click(object sender, System.EventArgs e)
{
button1.Enabled = false;
StatusPacketDumper statusDumper = new StatusPacketDumper(writer);
oThread = new Thread(new ThreadStart(statusDumper.run));
oThread.Start();
}

The writer is a TextWriter that displays it's output into my program's
TextBox. (I would love to instead just run this program as a
command-line utility but there's no such thing in CF right?).

The thread's StatusPacketDumper.run() method eventually calls
UdpClient.Receive().

Am I being bad here?

Any references to good books/resources that will help me learn the rules?

Thanks!

John
How are you deciding how many of the packets were received? Counting them
in the code that calls UdpClient.Receive()? You aren't doing that in the
user interface thread, right?

Paul T.

I'm new to the Compact Framework and C# but have been programming for
years, but not on small devices.

I have written a program running on Dell Axim that receives UDP packets.
that was converted from java using the tool provided by Microsoft. It
creates a TextBox to display messages (like "packet received" etc) and a
button. When the button is pressed the program listens for UDP packets
on port 51800.

On my desktop PC I then run a program that creates packets and sends
them to the proper IP address/port. Early in my learning process I
learned that I needed to disconnect the Axim from the cradle and use the
wireless network for receiving network traffic. I *DO* receive some of
the UDP packets, so my problem is not that I can't receive any data ---
my problem is that delivery seems unreliable even by UDP standards.

Out of 100 packets (each 10 bytes) sent (with a delay of 500 or 1000 ms
between packets) my program receives 10-12 of them. I also tried 256
byte packets and 1024 with similar disappointing results.

Is this normal on these little devices? Am I expecting too much? I
know that UDP is not guaranteed but this seems so bad that I can only
assume my program is flawed.

I can provide more code if needed. A UdpClient is used to receive the
data. Here's the receive method if that helps.

THANKS!

public static void Receive(System.Net.Sockets.UdpClient tempClient,
out PacketSupport packet)
{
System.Net.IPEndPoint remoteIpEndPoint =
new System.Net.IPEndPoint(System.Net.IPAddress.Any, 0);

PacketSupport tempPacket;
try
{
byte[] data_in = tempClient.Receive(ref remoteIpEndPoint);
tempPacket = new PacketSupport(data_in, data_in.Length);
tempPacket.IPEndPoint = remoteIpEndPoint;
}
catch ( System.Exception e )
{
throw new System.Exception(e.Message);
}
packet = tempPacket;
}
Click to expand...
Click to expand...
 
Ummmmm maybe. Sounds like I'm breaking the rules. In my Form.cs file I
create a thread when a button is clicked, like this:

private void button1_Click(object sender, System.EventArgs e)
{
button1.Enabled = false;
StatusPacketDumper statusDumper = new StatusPacketDumper(writer);
oThread = new Thread(new ThreadStart(statusDumper.run));
oThread.Start();
}

The writer is a TextWriter that displays it's output into my program's
TextBox. (I would love to instead just run this program as a
command-line utility but there's no such thing in CF right?).

The thread's StatusPacketDumper.run() method eventually calls
UdpClient.Receive().

Am I being bad here?

Any references to good books/resources that will help me learn the rules?

Thanks!

John


How are you deciding how many of the packets were received? Counting them
in the code that calls UdpClient.Receive()? You aren't doing that in the
user interface thread, right?

Paul T.

I'm new to the Compact Framework and C# but have been programming for
years, but not on small devices.

I have written a program running on Dell Axim that receives UDP packets.
that was converted from java using the tool provided by Microsoft. It
creates a TextBox to display messages (like "packet received" etc) and a
button. When the button is pressed the program listens for UDP packets
on port 51800.

On my desktop PC I then run a program that creates packets and sends
them to the proper IP address/port. Early in my learning process I
learned that I needed to disconnect the Axim from the cradle and use the
wireless network for receiving network traffic. I *DO* receive some of
the UDP packets, so my problem is not that I can't receive any data ---
my problem is that delivery seems unreliable even by UDP standards.

Out of 100 packets (each 10 bytes) sent (with a delay of 500 or 1000 ms
between packets) my program receives 10-12 of them. I also tried 256
byte packets and 1024 with similar disappointing results.

Is this normal on these little devices? Am I expecting too much? I
know that UDP is not guaranteed but this seems so bad that I can only
assume my program is flawed.

I can provide more code if needed. A UdpClient is used to receive the
data. Here's the receive method if that helps.

THANKS!

public static void Receive(System.Net.Sockets.UdpClient tempClient,
out PacketSupport packet)
{
System.Net.IPEndPoint remoteIpEndPoint =
new System.Net.IPEndPoint(System.Net.IPAddress.Any, 0);

PacketSupport tempPacket;
try
{
byte[] data_in = tempClient.Receive(ref remoteIpEndPoint);
tempPacket = new PacketSupport(data_in, data_in.Length);
tempPacket.IPEndPoint = remoteIpEndPoint;
}
catch ( System.Exception e )
{
throw new System.Exception(e.Message);
}
packet = tempPacket;
}
Click to expand...
Click to expand...
 
For this application, some packet loss is OK. But the 80-90% failure
that I'm seeing is no good. The device originating the traffic is
sending UDP packets. Data integrity is not an issue.

I've worked with UDP before; I've just never seen it so flaky before but
I'm new to wireless networking and Pocket PC. I want to learn if the
Pocket PC is simply incapable of handling UDP in a decent manner or
(more likely) my code is the problem.

Thanks!

John
I'm new to the Compact Framework and C# but have been programming for
years, but not on small devices.

I have written a program running on Dell Axim that receives UDP packets.
that was converted from java using the tool provided by Microsoft. It
creates a TextBox to display messages (like "packet received" etc) and a
button. When the button is pressed the program listens for UDP packets
on port 51800.

On my desktop PC I then run a program that creates packets and sends
them to the proper IP address/port. Early in my learning process I
learned that I needed to disconnect the Axim from the cradle and use the
wireless network for receiving network traffic. I *DO* receive some of
the UDP packets, so my problem is not that I can't receive any data ---
my problem is that delivery seems unreliable even by UDP standards.

Out of 100 packets (each 10 bytes) sent (with a delay of 500 or 1000 ms
between packets) my program receives 10-12 of them. I also tried 256
byte packets and 1024 with similar disappointing results.

Is this normal on these little devices? Am I expecting too much? I
know that UDP is not guaranteed but this seems so bad that I can only
assume my program is flawed.

I can provide more code if needed. A UdpClient is used to receive the
data. Here's the receive method if that helps.

THANKS!

public static void Receive(System.Net.Sockets.UdpClient tempClient,
out PacketSupport packet)
{
System.Net.IPEndPoint remoteIpEndPoint =
new System.Net.IPEndPoint(System.Net.IPAddress.Any, 0);

PacketSupport tempPacket;
try
{
byte[] data_in = tempClient.Receive(ref remoteIpEndPoint);
tempPacket = new PacketSupport(data_in, data_in.Length);
tempPacket.IPEndPoint = remoteIpEndPoint;
}
catch ( System.Exception e )
{
throw new System.Exception(e.Message);
}
packet = tempPacket;
}
Click to expand...


In general, if you are looking towards using UDP and packet loss is
unacceptable you have two solutions.

1) Build a "smarter" protocol on top of UDP which implements sequence
numbers, resends, acks, etc..
2) Switch to TCP which already has sequence numbers, resends, acks, etc...

Most people would choose #2 and be on their merry way. Plain old UDP is not
reliable. It really depends on the networks, routers, etc... I wouldn't
waste much time on this issue. It is the nature of the beast. The only
feasible situation for using plain old UDP is in a video game or something
like that where speed is more important than data integrity or where data
integrity is not important at all.
Click to expand...
 
Stronlgy suspecting my code now...

I ran my same code on the desktop machine, using a TextBox to display
the packet info and I got similar, poor, results -- only a handful of
packets are received.

Then I ran that same code as a console app on the desktop and 100% of
the packets are received.

So I suspect that packets are being received properly; its just that my
code to report the packet arrivals in a TextBox is flawed.

Will try the PocketConsole on the Axim now.

John

@ said:
For this application, some packet loss is OK. But the 80-90% failure
that I'm seeing is no good. The device originating the traffic is
sending UDP packets. Data integrity is not an issue.

I've worked with UDP before; I've just never seen it so flaky before but
I'm new to wireless networking and Pocket PC. I want to learn if the
Pocket PC is simply incapable of handling UDP in a decent manner or
(more likely) my code is the problem.

Thanks!

John
message
I'm new to the Compact Framework and C# but have been programming for
years, but not on small devices.

I have written a program running on Dell Axim that receives UDP packets.
that was converted from java using the tool provided by Microsoft. It
creates a TextBox to display messages (like "packet received" etc) and a
button. When the button is pressed the program listens for UDP packets
on port 51800.

On my desktop PC I then run a program that creates packets and sends
them to the proper IP address/port. Early in my learning process I
learned that I needed to disconnect the Axim from the cradle and use the
wireless network for receiving network traffic. I *DO* receive some of
the UDP packets, so my problem is not that I can't receive any data
--- my problem is that delivery seems unreliable even by UDP standards.

Out of 100 packets (each 10 bytes) sent (with a delay of 500 or 1000 ms
between packets) my program receives 10-12 of them. I also tried 256
byte packets and 1024 with similar disappointing results.

Is this normal on these little devices? Am I expecting too much? I
know that UDP is not guaranteed but this seems so bad that I can only
assume my program is flawed.

I can provide more code if needed. A UdpClient is used to receive the
data. Here's the receive method if that helps.

THANKS!

public static void Receive(System.Net.Sockets.UdpClient tempClient,
out PacketSupport packet)
{
System.Net.IPEndPoint remoteIpEndPoint =
new System.Net.IPEndPoint(System.Net.IPAddress.Any, 0);

PacketSupport tempPacket;
try
{
byte[] data_in = tempClient.Receive(ref remoteIpEndPoint);
tempPacket = new PacketSupport(data_in, data_in.Length);
tempPacket.IPEndPoint = remoteIpEndPoint;
}
catch ( System.Exception e )
{
throw new System.Exception(e.Message);
}
packet = tempPacket;
}
Click to expand...



In general, if you are looking towards using UDP and packet loss is
unacceptable you have two solutions.

1) Build a "smarter" protocol on top of UDP which implements sequence
numbers, resends, acks, etc..
2) Switch to TCP which already has sequence numbers, resends, acks,
etc...

Most people would choose #2 and be on their merry way. Plain old UDP
is not
reliable. It really depends on the networks, routers, etc... I wouldn't
waste much time on this issue. It is the nature of the beast. The only
feasible situation for using plain old UDP is in a video game or
something
like that where speed is more important than data integrity or where data
integrity is not important at all.
Click to expand...
Click to expand...
 
I now am running this code as a "Non-Graphical Application" and am using
PocketConsole to allow me to see Console.WriteLine() calls. I'm so
happy to have this stuff -- thanks to all who suggested it.

I assume I no longer have arcane thread issues to deal with?

I am able to receive UDP packets but it is very unreliable... out of 100
packets sent from a desktop PC I'll typically receive 10 or 12 on the
Pocket PC.

Is this as good as it gets I wonder?

Thanks!

John
How are you deciding how many of the packets were received? Counting them
in the code that calls UdpClient.Receive()? You aren't doing that in the
user interface thread, right?

Paul T.

I'm new to the Compact Framework and C# but have been programming for
years, but not on small devices.

I have written a program running on Dell Axim that receives UDP packets.
that was converted from java using the tool provided by Microsoft. It
creates a TextBox to display messages (like "packet received" etc) and a
button. When the button is pressed the program listens for UDP packets
on port 51800.

On my desktop PC I then run a program that creates packets and sends
them to the proper IP address/port. Early in my learning process I
learned that I needed to disconnect the Axim from the cradle and use the
wireless network for receiving network traffic. I *DO* receive some of
the UDP packets, so my problem is not that I can't receive any data ---
my problem is that delivery seems unreliable even by UDP standards.

Out of 100 packets (each 10 bytes) sent (with a delay of 500 or 1000 ms
between packets) my program receives 10-12 of them. I also tried 256
byte packets and 1024 with similar disappointing results.

Is this normal on these little devices? Am I expecting too much? I
know that UDP is not guaranteed but this seems so bad that I can only
assume my program is flawed.

I can provide more code if needed. A UdpClient is used to receive the
data. Here's the receive method if that helps.

THANKS!

public static void Receive(System.Net.Sockets.UdpClient tempClient,
out PacketSupport packet)
{
System.Net.IPEndPoint remoteIpEndPoint =
new System.Net.IPEndPoint(System.Net.IPAddress.Any, 0);

PacketSupport tempPacket;
try
{
byte[] data_in = tempClient.Receive(ref remoteIpEndPoint);
tempPacket = new PacketSupport(data_in, data_in.Length);
tempPacket.IPEndPoint = remoteIpEndPoint;
}
catch ( System.Exception e )
{
throw new System.Exception(e.Message);
}
packet = tempPacket;
}
Click to expand...
Click to expand...
 
Perhaps you are talking to the UI from a thread other than the GUI thread
without using Invoke? Or maybe you are spending so much time in invoking
the main thread that you are not ready to receive packets when they arrive.
If they all come in a bunch and you are not waiting for them as they arrive,
at least some of the time, the TCP/IP stack will not be able to queue them
all...

Paul T.

@ *SPAM* yahoo_com said:
Stronlgy suspecting my code now...

I ran my same code on the desktop machine, using a TextBox to display
the packet info and I got similar, poor, results -- only a handful of
packets are received.

Then I ran that same code as a console app on the desktop and 100% of
the packets are received.

So I suspect that packets are being received properly; its just that my
code to report the packet arrivals in a TextBox is flawed.

Will try the PocketConsole on the Axim now.

John

@ said:
For this application, some packet loss is OK. But the 80-90% failure
that I'm seeing is no good. The device originating the traffic is
sending UDP packets. Data integrity is not an issue.

I've worked with UDP before; I've just never seen it so flaky before but
I'm new to wireless networking and Pocket PC. I want to learn if the
Pocket PC is simply incapable of handling UDP in a decent manner or
(more likely) my code is the problem.

Thanks!

John
message

I'm new to the Compact Framework and C# but have been programming for
years, but not on small devices.

I have written a program running on Dell Axim that receives UDP packets.
that was converted from java using the tool provided by Microsoft. It
creates a TextBox to display messages (like "packet received" etc) and a
button. When the button is pressed the program listens for UDP packets
on port 51800.

On my desktop PC I then run a program that creates packets and sends
them to the proper IP address/port. Early in my learning process I
learned that I needed to disconnect the Axim from the cradle and use the
wireless network for receiving network traffic. I *DO* receive some of
the UDP packets, so my problem is not that I can't receive any data
--- my problem is that delivery seems unreliable even by UDP standards.

Out of 100 packets (each 10 bytes) sent (with a delay of 500 or 1000 ms
between packets) my program receives 10-12 of them. I also tried 256
byte packets and 1024 with similar disappointing results.

Is this normal on these little devices? Am I expecting too much? I
know that UDP is not guaranteed but this seems so bad that I can only
assume my program is flawed.

I can provide more code if needed. A UdpClient is used to receive the
data. Here's the receive method if that helps.

THANKS!

public static void Receive(System.Net.Sockets.UdpClient tempClient,
out PacketSupport packet)
{
System.Net.IPEndPoint remoteIpEndPoint =
new System.Net.IPEndPoint(System.Net.IPAddress.Any, 0);

PacketSupport tempPacket;
try
{
byte[] data_in = tempClient.Receive(ref remoteIpEndPoint);
tempPacket = new PacketSupport(data_in, data_in.Length);
tempPacket.IPEndPoint = remoteIpEndPoint;
}
catch ( System.Exception e )
{
throw new System.Exception(e.Message);
}
packet = tempPacket;
}



In general, if you are looking towards using UDP and packet loss is
unacceptable you have two solutions.

1) Build a "smarter" protocol on top of UDP which implements sequence
numbers, resends, acks, etc..
2) Switch to TCP which already has sequence numbers, resends, acks,
etc...

Most people would choose #2 and be on their merry way. Plain old UDP
is not
reliable. It really depends on the networks, routers, etc... I wouldn't
waste much time on this issue. It is the nature of the beast. The only
feasible situation for using plain old UDP is in a video game or
something
like that where speed is more important than data integrity or where data
integrity is not important at all.
Click to expand...
Click to expand...
Click to expand...
 
Problem solved -- thanks for your advice and attention.

The problem turned out to be rather mundane (and perhaps embarrassing
for me). There is a setting for "Power Save Mode" in my Pocket PC's
WLAN control panel. The default is "Auto". When I disable this
setting the UDP performance goes from dismal (about 10% success) to
stellar (near 100% as far as I can tell).

I had read references to disabling power save mode but I thought that
referred to the various settings related to automatically turning off
the device if unused. I was mistaken.

Sincerely,

John Lindwall

Perhaps you are talking to the UI from a thread other than the GUI thread
without using Invoke? Or maybe you are spending so much time in invoking
the main thread that you are not ready to receive packets when they arrive.
If they all come in a bunch and you are not waiting for them as they arrive,
at least some of the time, the TCP/IP stack will not be able to queue them
all...

Paul T.

Stronlgy suspecting my code now...

I ran my same code on the desktop machine, using a TextBox to display
the packet info and I got similar, poor, results -- only a handful of
packets are received.

Then I ran that same code as a console app on the desktop and 100% of
the packets are received.

So I suspect that packets are being received properly; its just that my
code to report the packet arrivals in a TextBox is flawed.

Will try the PocketConsole on the Axim now.

John

@ said:
For this application, some packet loss is OK. But the 80-90% failure
that I'm seeing is no good. The device originating the traffic is
sending UDP packets. Data integrity is not an issue.

I've worked with UDP before; I've just never seen it so flaky before but
I'm new to wireless networking and Pocket PC. I want to learn if the
Pocket PC is simply incapable of handling UDP in a decent manner or
(more likely) my code is the problem.

Thanks!

John

Trevor wrote:


message


I'm new to the Compact Framework and C# but have been programming for
years, but not on small devices.

I have written a program running on Dell Axim that receives UDP
Click to expand...
packets.
that was converted from java using the tool provided by Microsoft.
Click to expand...
It
creates a TextBox to display messages (like "packet received" etc) and
Click to expand...
a
button. When the button is pressed the program listens for UDP
Click to expand...
packets
on port 51800.

On my desktop PC I then run a program that creates packets and sends
them to the proper IP address/port. Early in my learning process I
learned that I needed to disconnect the Axim from the cradle and use
Click to expand...
the
wireless network for receiving network traffic. I *DO* receive some
Click to expand...
of
the UDP packets, so my problem is not that I can't receive any data
--- my problem is that delivery seems unreliable even by UDP
Click to expand...
standards.
Out of 100 packets (each 10 bytes) sent (with a delay of 500 or 1000
Click to expand...
ms
between packets) my program receives 10-12 of them. I also tried 256
byte packets and 1024 with similar disappointing results.

Is this normal on these little devices? Am I expecting too much? I
know that UDP is not guaranteed but this seems so bad that I can only
assume my program is flawed.

I can provide more code if needed. A UdpClient is used to receive the
data. Here's the receive method if that helps.

THANKS!

public static void Receive(System.Net.Sockets.UdpClient tempClient,
out PacketSupport packet)
{
System.Net.IPEndPoint remoteIpEndPoint =
new System.Net.IPEndPoint(System.Net.IPAddress.Any, 0);

PacketSupport tempPacket;
try
{
byte[] data_in = tempClient.Receive(ref remoteIpEndPoint);
tempPacket = new PacketSupport(data_in, data_in.Length);
tempPacket.IPEndPoint = remoteIpEndPoint;
}
catch ( System.Exception e )
{
throw new System.Exception(e.Message);
}
packet = tempPacket;
}



In general, if you are looking towards using UDP and packet loss is
unacceptable you have two solutions.

1) Build a "smarter" protocol on top of UDP which implements sequence
numbers, resends, acks, etc..
2) Switch to TCP which already has sequence numbers, resends, acks,
etc...

Most people would choose #2 and be on their merry way. Plain old UDP
is not
reliable. It really depends on the networks, routers, etc... I
Click to expand...
wouldn't
waste much time on this issue. It is the nature of the beast. The
Click to expand...
only
feasible situation for using plain old UDP is in a video game or
something
like that where speed is more important than data integrity or where
Click to expand...
data
integrity is not important at all.
Click to expand...
Click to expand...
Click to expand...
 
So, it's just mislabeled, I guess! "[X] Mundane performance"...

Paul T.

John Lindwall said:
Problem solved -- thanks for your advice and attention.

The problem turned out to be rather mundane (and perhaps embarrassing
for me). There is a setting for "Power Save Mode" in my Pocket PC's
WLAN control panel. The default is "Auto". When I disable this
setting the UDP performance goes from dismal (about 10% success) to
stellar (near 100% as far as I can tell).

I had read references to disabling power save mode but I thought that
referred to the various settings related to automatically turning off
the device if unused. I was mistaken.

Sincerely,

John Lindwall

Perhaps you are talking to the UI from a thread other than the GUI thread
without using Invoke? Or maybe you are spending so much time in invoking
the main thread that you are not ready to receive packets when they arrive.
If they all come in a bunch and you are not waiting for them as they arrive,
at least some of the time, the TCP/IP stack will not be able to queue them
all...

Paul T.

Stronlgy suspecting my code now...

I ran my same code on the desktop machine, using a TextBox to display
the packet info and I got similar, poor, results -- only a handful of
packets are received.

Then I ran that same code as a console app on the desktop and 100% of
the packets are received.

So I suspect that packets are being received properly; its just that my
code to report the packet arrivals in a TextBox is flawed.

Will try the PocketConsole on the Axim now.

John

@ wrote:

For this application, some packet loss is OK. But the 80-90% failure
that I'm seeing is no good. The device originating the traffic is
sending UDP packets. Data integrity is not an issue.

I've worked with UDP before; I've just never seen it so flaky before but
I'm new to wireless networking and Pocket PC. I want to learn if the
Pocket PC is simply incapable of handling UDP in a decent manner or
(more likely) my code is the problem.

Thanks!

John

Trevor wrote:


message


I'm new to the Compact Framework and C# but have been programming for
years, but not on small devices.

I have written a program running on Dell Axim that receives UDP
packets.

that was converted from java using the tool provided by Microsoft.
It

creates a TextBox to display messages (like "packet received" etc)
Click to expand...
and

a
button. When the button is pressed the program listens for UDP
packets

on port 51800.

On my desktop PC I then run a program that creates packets and sends
them to the proper IP address/port. Early in my learning process I
learned that I needed to disconnect the Axim from the cradle and use
the

wireless network for receiving network traffic. I *DO* receive some
of

the UDP packets, so my problem is not that I can't receive any data
--- my problem is that delivery seems unreliable even by UDP
standards.

Out of 100 packets (each 10 bytes) sent (with a delay of 500 or 1000
ms

between packets) my program receives 10-12 of them. I also tried 256
byte packets and 1024 with similar disappointing results.

Is this normal on these little devices? Am I expecting too much? I
know that UDP is not guaranteed but this seems so bad that I can only
assume my program is flawed.

I can provide more code if needed. A UdpClient is used to receive the
data. Here's the receive method if that helps.

THANKS!

public static void Receive(System.Net.Sockets.UdpClient tempClient,
out PacketSupport packet)
{
System.Net.IPEndPoint remoteIpEndPoint =
new System.Net.IPEndPoint(System.Net.IPAddress.Any, 0);

PacketSupport tempPacket;
try
{
byte[] data_in = tempClient.Receive(ref remoteIpEndPoint);
tempPacket = new PacketSupport(data_in, data_in.Length);
tempPacket.IPEndPoint = remoteIpEndPoint;
}
catch ( System.Exception e )
{
throw new System.Exception(e.Message);
}
packet = tempPacket;
}



In general, if you are looking towards using UDP and packet loss is
unacceptable you have two solutions.

1) Build a "smarter" protocol on top of UDP which implements sequence
numbers, resends, acks, etc..
2) Switch to TCP which already has sequence numbers, resends, acks,
etc...

Most people would choose #2 and be on their merry way. Plain old UDP
is not
reliable. It really depends on the networks, routers, etc... I
wouldn't

waste much time on this issue. It is the nature of the beast. The
only

feasible situation for using plain old UDP is in a video game or
something
like that where speed is more important than data integrity or where
data

integrity is not important at all.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top