udp buffer issue

C

cmhada

I have some code that continually reads packets off of a udp port
where the incoming packets are 26 bytes in length.

CODE: byte[] recBytes = udpClient.Receive(ref ipEndPoint);

I have left the udp buffer length at the default 8192. After
approximately 320 packets have been read, packets are being missed,
almost like the buffer is full and is not queueing incoming packets
any longer. 320 lines * 26 bytes = ~ the size of the udp buffer. If
I increase the buffer size, the problem is delayed proportionally. Is
there some way that the buffer would back up where the Receive() calls
would not dequeue? (I am making some assumptions on how the udp queue
functions internally, so please forgive me if I have made the wrong
assumptions here.)

I have other code that uses the same logic and it does not experience
this issue, which is really strange to me.

Any help would be greatly appreciated.

Thanks,

Chris
 
P

Peter Duniho

I have some code that continually reads packets off of a udp port
where the incoming packets are 26 bytes in length.

[...]
Is
there some way that the buffer would back up where the Receive() calls
would not dequeue?
Click to expand...

Not assuming you are actually calling Receive(), no. Receive() consumes
the received data.

You will need to post a concise-but-complete example of code that
reliably reproduces the problem. The single line of code you posted is
not anywhere close to properly representing what you're actually doing
in your code.

Note also that for networking code, "complete" means that you post both
sending and receiving code. For any example, "concise" means that you
reduce the code to the bare minimum required to reproduce the problem.

Pete
 
C

cmhada

[email protected] said:
I have some code that continually reads packets off of a udp port
where the incoming packets are 26 bytes in length.
Click to expand...
[...]
Is
there some way that the buffer would back up where the Receive() calls
would not dequeue?
Click to expand...

Not assuming you are actually calling Receive(), no. Receive() consumes
the received data.

You will need to post a concise-but-complete example of code that
reliably reproduces the problem. The single line of code you posted is
not anywhere close to properly representing what you're actually doing
in your code.

Note also that for networking code, "complete" means that you post both
sending and receiving code. For any example, "concise" means that you
reduce the code to the bare minimum required to reproduce the problem.

Pete
Click to expand...

Hi Pete,

Line 334 is where the sequence number jumps (byte 21) from BE to FB.
I don't have the code that sends the packets...it's an embedded system
outside of my reach, but I have pasted some source code below for the
receiving portion of the code and the console output. The packets are
all 26 bytes long though. I can see them using Wireshark to verify
their content.

Thanks,

Chris

--------------------------------------

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Windows.Forms;

namespace TestUDP
{
public partial class Form1 : Form
{
bool stopReading = false;

public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
UdpClient udpClient = new UdpClient(5002);
IPEndPoint ipEndPoint = new IPEndPoint(IPAddress.Any,
5002);

int lineCounter = 0;

while (!stopReading)
{
byte[] recBytes = udpClient.Receive(ref ipEndPoint);
foreach (byte b in recBytes)
Console.Write(b.ToString("X2") + @" ");
Console.WriteLine(@" Line:" + ++lineCounter);
Application.DoEvents();
}

udpClient.Close();
this.Close();

}

private void button2_Click(object sender, EventArgs e)
{
stopReading = true;
}
}
}

--------------------

CONSOLE OUTPUT --->

00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 4C 00 00 BC 58
00 00 00 Line:307
00 1A B8 00 00 36 00 85 D1 B0 00 02 04 00 85 D1 00 03 4C 00 00 BC 35
00 00 00 Line:308
00 1A B8 00 00 5A 00 85 D1 B0 00 05 04 00 85 D1 00 03 4C 00 00 BC 5A
00 00 00 Line:309
00 1A B8 00 00 52 00 85 D1 B0 00 04 04 00 85 D1 00 03 4C 00 00 BC 42
00 00 00 Line:310
00 1A B8 00 00 3A 00 85 D1 B0 00 03 04 00 85 D1 00 03 4C 00 00 BC 43
00 00 00 Line:311
00 1A B8 00 00 38 00 85 D1 B0 00 06 04 00 85 D1 00 03 4C 00 00 BC 3F
00 00 00 Line:312
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 4C 00 00 BC 4A
00 00 00 Line:313
00 1A B8 00 00 16 00 85 D1 B0 00 00 04 00 85 D1 00 03 4C 00 00 BC 52
00 00 00 Line:314
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 4C 00 00 BC 00
00 00 00 Line:315
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 4D 00 00 BD 58
00 00 00 Line:316
00 1A B8 00 00 36 00 85 D1 B0 00 02 04 00 85 D1 00 03 4D 00 00 BD 35
00 00 00 Line:317
00 1A B8 00 00 5A 00 85 D1 B0 00 05 04 00 85 D1 00 03 4D 00 00 BD 5A
00 00 00 Line:318
00 1A B8 00 00 16 00 85 D1 B0 00 00 04 00 85 D1 00 03 4D 00 00 BD 52
00 00 00 Line:319
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 4D 00 00 BD 4A
00 00 00 Line:320
00 1A B8 00 00 52 00 85 D1 B0 00 04 04 00 85 D1 00 03 4D 00 00 BD 42
00 00 00 Line:321
00 1A B8 00 00 3A 00 85 D1 B0 00 03 04 00 85 D1 00 03 4D 00 00 BD 43
00 00 00 Line:322
00 1A B8 00 00 38 00 85 D1 B0 00 06 04 00 85 D1 00 03 4D 00 00 BD 3F
00 00 00 Line:323
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 4D 00 00 BD 00
00 00 00 Line:324
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 4E 00 00 BE 58
00 00 00 Line:325
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 4E 00 00 BE 4A
00 00 00 Line:326
00 1A B8 00 00 36 00 85 D1 B0 00 02 04 00 85 D1 00 03 4E 00 00 BE 34
00 00 00 Line:327
00 1A B8 00 00 5A 00 85 D1 B0 00 05 04 00 85 D1 00 03 4E 00 00 BE 5A
00 00 00 Line:328
00 1A B8 00 00 16 00 85 D1 B0 00 00 04 00 85 D1 00 03 4E 00 00 BE 52
00 00 00 Line:329
00 1A B8 00 00 52 00 85 D1 B0 00 04 04 00 85 D1 00 03 4E 00 00 BE 42
00 00 00 Line:330
00 1A B8 00 00 3A 00 85 D1 B0 00 03 04 00 85 D1 00 03 4E 00 00 BE 43
00 00 00 Line:331
00 1A B8 00 00 38 00 85 D1 B0 00 06 04 00 85 D1 00 03 4E 00 00 BE 3F
00 00 00 Line:332
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 4E 00 00 BE 00
00 00 00 Line:333
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 8B 00 00 FB 57
00 00 00 Line:334
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 8B 00 00 FB 49
00 00 00 Line:335
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 8B 00 00 FB 00
00 00 00 Line:336
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 8C 00 00 FC 58
00 00 00 Line:337
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 8C 00 00 FC 49
00 00 00 Line:338
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 8D 00 00 FD 58
00 00 00 Line:339
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 8D 00 00 FD 4A
00 00 00 Line:340
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 8D 00 00 FD 00
00 00 00 Line:341
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 8E 00 00 FE 58
00 00 00 Line:342
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 8E 00 00 FE 4A
00 00 00 Line:343
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 8F 00 00 FF 58
00 00 00 Line:344
00 1A B8 00 00 5A 00 85 D1 B0 00 05 04 00 85 D1 00 03 8F 00 00 FF 5A
00 00 00 Line:345
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 DC 00 00 4C 58
00 00 00 Line:346
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 DD 00 00 4D 57
00 00 00 Line:347
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 DD 00 00 4D 49
00 00 00 Line:348
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 DD 00 00 4D 00
00 00 00 Line:349
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 DE 00 00 4E 57
00 00 00 Line:350
 
P

Peter Duniho

Line 334 is where the sequence number jumps (byte 21) from BE to FB.
Click to expand...

Ah. So you don't stop receiving data, you just lose some.

Well, that's different. The first thing you need to be aware of is that
UDP doesn't guarantee delivery of your data. It also does not
guarantee that data that is delivered arrives in the order in which it
was sent. Finally, it also does not guarantee that data that is
delivered is only delivered once.

Now, in your case, I would guess that the issue is that you are not
receiving the data fast enough. Data that's sent to you while you are
busy doing other things may well be discarded. Given your inefficient
processing of the data (writing the results to the console, which is
slow in the first place, and then doing it one byte at a time, which
just slows it down even more), I'm not all that surprised that you are
losing data.

The fix is to make your data processing more efficient. As a first try,
you might want to format your data into a single string, which you then
write to the console. If that doesn't work, you'll need to be more
elaborate. Maybe by reducing the data you output (just write the
sequence number and length of the datagram, for example).

If that still doesn't help, one possibility would be to use
Begin/EndReceive to receive data and queue it for output handled by
other code, so that your i/o is not tied to the user output. Keeping in
mind, of course, that if your output isn't as fast as the input, you
will of course eventually run out of memory queuing the data, and also
of course the output won't be real-time, since it will always lag behind
the input.

Of course, IMHO the very first thing to try is take the output code out
all together, doing some simple checking on the data received to verify
that without the output code, you get the data as you expect (or at
least, reasonably close to it, keeping in mind the limitations of UDP).

For example:

byte bSequencePrev;

while (!stopReading)
{
byte bSequenceCur;
byte[] recBytes = udpClient.Receive(ref ipEndPoint);

bSequenceCur = recBytes[21];
if (bSequenceCur > bSequencePrev + 1)
{
Console.WriteLine("lost data");
}

Application.DoEvents();
}

Finally, the one last comment I have is that you should redesign your
code so that you don't need to call DoEvents(). There are a variety of
reasons that's not good form, but in this case one of the most obvious
reasons is that it's just one more thing that can slow down your i/o
code, resulting in lost data. When you call DoEvents() you have no
control over what might wind up being done; most of the time it would
probably be okay, but if some time-consuming operation winds up in
there, you are at the mercy of that operation.

Much better would be to use Begin/EndReceive, as I already suggested for
other reasons. Alternatively, put your i/o code in its own thread,
separate from the UI's thread.
I don't have the code that sends the packets...it's an embedded system
outside of my reach, [...]
Click to expand...

You may not need to post more code in this case. However, for future
reference, just because you can't post the embedded system, that doesn't
mean you can't post code that simulates the embedded system.

Yes, this is more work for you. But really, it's often the only way to
get anyone to help. You need to be willing to put enough work in up
front so that someone else has some actual useful information to work with.

As an added benefit, the exercise often helps you answer your own
question yourself. :)

Pete
 
C

cmhada

[email protected] said:
Line 334 is where the sequence number jumps (byte 21) from BE to FB.
Click to expand...

Ah. So you don't stop receiving data, you just lose some.

Well, that's different. The first thing you need to be aware of is that
UDP doesn't guarantee delivery of your data. It also does not
guarantee that data that is delivered arrives in the order in which it
was sent. Finally, it also does not guarantee that data that is
delivered is only delivered once.

Now, in your case, I would guess that the issue is that you are not
receiving the data fast enough. Data that's sent to you while you are
busy doing other things may well be discarded. Given your inefficient
processing of the data (writing the results to the console, which is
slow in the first place, and then doing it one byte at a time, which
just slows it down even more), I'm not all that surprised that you are
losing data.

The fix is to make your data processing more efficient. As a first try,
you might want to format your data into a single string, which you then
write to the console. If that doesn't work, you'll need to be more
elaborate. Maybe by reducing the data you output (just write the
sequence number and length of the datagram, for example).

If that still doesn't help, one possibility would be to use
Begin/EndReceive to receive data and queue it for output handled by
other code, so that your i/o is not tied to the user output. Keeping in
mind, of course, that if your output isn't as fast as the input, you
will of course eventually run out of memory queuing the data, and also
of course the output won't be real-time, since it will always lag behind
the input.

Of course, IMHO the very first thing to try is take the output code out
all together, doing some simple checking on the data received to verify
that without the output code, you get the data as you expect (or at
least, reasonably close to it, keeping in mind the limitations of UDP).

For example:

byte bSequencePrev;

while (!stopReading)
{
byte bSequenceCur;
byte[] recBytes = udpClient.Receive(ref ipEndPoint);

bSequenceCur = recBytes[21];
if (bSequenceCur > bSequencePrev + 1)
{
Console.WriteLine("lost data");
}

Application.DoEvents();
}

Finally, the one last comment I have is that you should redesign your
code so that you don't need to call DoEvents(). There are a variety of
reasons that's not good form, but in this case one of the most obvious
reasons is that it's just one more thing that can slow down your i/o
code, resulting in lost data. When you call DoEvents() you have no
control over what might wind up being done; most of the time it would
probably be okay, but if some time-consuming operation winds up in
there, you are at the mercy of that operation.

Much better would be to use Begin/EndReceive, as I already suggested for
other reasons. Alternatively, put your i/o code in its own thread,
separate from the UI's thread.
I don't have the code that sends the packets...it's an embedded system
outside of my reach, [...]
Click to expand...

You may not need to post more code in this case. However, for future
reference, just because you can't post the embedded system, that doesn't
mean you can't post code that simulates the embedded system.

Yes, this is more work for you. But really, it's often the only way to
get anyone to help. You need to be willing to put enough work in up
front so that someone else has some actual useful information to work with.

As an added benefit, the exercise often helps you answer your own
question yourself. :)

Pete
Click to expand...

Hi Pete,

I actually do have the i/o code in its own thread and I send a 1-byte
0xFF packet from the on-click handler of the stop button to the UDP
port so that the i/o thread can terminate itself and reutrn from the
thread.start() call gracefully. You are right in saying that the
Application.DoEvents() is a hack...it still barely responds even at
that. I had consolidated the code into what I sent you figuring that
it would be easier to follow than multi-threaded code, but it probably
just made my code look even worse. :) I did not realize that the
console output was so slow. I have a logger in my i/o thread that
writes output to a text file a line at a time, so maybe I will remove
the console i/o code and see if that speeds things up. I appreciate
all of your help and next time I will send a better representation of
what I am doing to make things easier for whomever is debugging it.

Thanks!

Chris
 
L

Leon Lambert

You will miss messages if you are not in the receive method when they
arrive. Normal way to process this is to receive the data and pass the
buffer off to an other thread to process and quickly get back to the
receive methods.

Hope this helps.
Leon Lambert

[email protected] said:
I have some code that continually reads packets off of a udp port
where the incoming packets are 26 bytes in length.
[...]
Is
there some way that the buffer would back up where the Receive() calls
would not dequeue?
Click to expand...
Not assuming you are actually calling Receive(), no. Receive() consumes
the received data.

You will need to post a concise-but-complete example of code that
reliably reproduces the problem. The single line of code you posted is
not anywhere close to properly representing what you're actually doing
in your code.

Note also that for networking code, "complete" means that you post both
sending and receiving code. For any example, "concise" means that you
reduce the code to the bare minimum required to reproduce the problem.

Pete
Click to expand...


Hi Pete,

Line 334 is where the sequence number jumps (byte 21) from BE to FB.
I don't have the code that sends the packets...it's an embedded system
outside of my reach, but I have pasted some source code below for the
receiving portion of the code and the console output. The packets are
all 26 bytes long though. I can see them using Wireshark to verify
their content.

Thanks,

Chris

--------------------------------------

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Net;
using System.Net.Sockets;
using System.Text;
using System.Windows.Forms;

namespace TestUDP
{
public partial class Form1 : Form
{
bool stopReading = false;

public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
UdpClient udpClient = new UdpClient(5002);
IPEndPoint ipEndPoint = new IPEndPoint(IPAddress.Any,
5002);

int lineCounter = 0;

while (!stopReading)
{
byte[] recBytes = udpClient.Receive(ref ipEndPoint);
foreach (byte b in recBytes)
Console.Write(b.ToString("X2") + @" ");
Console.WriteLine(@" Line:" + ++lineCounter);
Application.DoEvents();
}

udpClient.Close();
this.Close();

}

private void button2_Click(object sender, EventArgs e)
{
stopReading = true;
}
}
}

--------------------

CONSOLE OUTPUT --->

00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 4C 00 00 BC 58
00 00 00 Line:307
00 1A B8 00 00 36 00 85 D1 B0 00 02 04 00 85 D1 00 03 4C 00 00 BC 35
00 00 00 Line:308
00 1A B8 00 00 5A 00 85 D1 B0 00 05 04 00 85 D1 00 03 4C 00 00 BC 5A
00 00 00 Line:309
00 1A B8 00 00 52 00 85 D1 B0 00 04 04 00 85 D1 00 03 4C 00 00 BC 42
00 00 00 Line:310
00 1A B8 00 00 3A 00 85 D1 B0 00 03 04 00 85 D1 00 03 4C 00 00 BC 43
00 00 00 Line:311
00 1A B8 00 00 38 00 85 D1 B0 00 06 04 00 85 D1 00 03 4C 00 00 BC 3F
00 00 00 Line:312
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 4C 00 00 BC 4A
00 00 00 Line:313
00 1A B8 00 00 16 00 85 D1 B0 00 00 04 00 85 D1 00 03 4C 00 00 BC 52
00 00 00 Line:314
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 4C 00 00 BC 00
00 00 00 Line:315
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 4D 00 00 BD 58
00 00 00 Line:316
00 1A B8 00 00 36 00 85 D1 B0 00 02 04 00 85 D1 00 03 4D 00 00 BD 35
00 00 00 Line:317
00 1A B8 00 00 5A 00 85 D1 B0 00 05 04 00 85 D1 00 03 4D 00 00 BD 5A
00 00 00 Line:318
00 1A B8 00 00 16 00 85 D1 B0 00 00 04 00 85 D1 00 03 4D 00 00 BD 52
00 00 00 Line:319
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 4D 00 00 BD 4A
00 00 00 Line:320
00 1A B8 00 00 52 00 85 D1 B0 00 04 04 00 85 D1 00 03 4D 00 00 BD 42
00 00 00 Line:321
00 1A B8 00 00 3A 00 85 D1 B0 00 03 04 00 85 D1 00 03 4D 00 00 BD 43
00 00 00 Line:322
00 1A B8 00 00 38 00 85 D1 B0 00 06 04 00 85 D1 00 03 4D 00 00 BD 3F
00 00 00 Line:323
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 4D 00 00 BD 00
00 00 00 Line:324
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 4E 00 00 BE 58
00 00 00 Line:325
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 4E 00 00 BE 4A
00 00 00 Line:326
00 1A B8 00 00 36 00 85 D1 B0 00 02 04 00 85 D1 00 03 4E 00 00 BE 34
00 00 00 Line:327
00 1A B8 00 00 5A 00 85 D1 B0 00 05 04 00 85 D1 00 03 4E 00 00 BE 5A
00 00 00 Line:328
00 1A B8 00 00 16 00 85 D1 B0 00 00 04 00 85 D1 00 03 4E 00 00 BE 52
00 00 00 Line:329
00 1A B8 00 00 52 00 85 D1 B0 00 04 04 00 85 D1 00 03 4E 00 00 BE 42
00 00 00 Line:330
00 1A B8 00 00 3A 00 85 D1 B0 00 03 04 00 85 D1 00 03 4E 00 00 BE 43
00 00 00 Line:331
00 1A B8 00 00 38 00 85 D1 B0 00 06 04 00 85 D1 00 03 4E 00 00 BE 3F
00 00 00 Line:332
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 4E 00 00 BE 00
00 00 00 Line:333
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 8B 00 00 FB 57
00 00 00 Line:334
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 8B 00 00 FB 49
00 00 00 Line:335
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 8B 00 00 FB 00
00 00 00 Line:336
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 8C 00 00 FC 58
00 00 00 Line:337
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 8C 00 00 FC 49
00 00 00 Line:338
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 8D 00 00 FD 58
00 00 00 Line:339
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 8D 00 00 FD 4A
00 00 00 Line:340
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 8D 00 00 FD 00
00 00 00 Line:341
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 8E 00 00 FE 58
00 00 00 Line:342
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 8E 00 00 FE 4A
00 00 00 Line:343
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 8F 00 00 FF 58
00 00 00 Line:344
00 1A B8 00 00 5A 00 85 D1 B0 00 05 04 00 85 D1 00 03 8F 00 00 FF 5A
00 00 00 Line:345
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 DC 00 00 4C 58
00 00 00 Line:346
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 DD 00 00 4D 57
00 00 00 Line:347
00 1A B8 00 00 46 00 85 D1 B0 00 01 04 00 85 D1 00 03 DD 00 00 4D 49
00 00 00 Line:348
00 1A B8 00 00 42 00 85 D1 A0 00 00 03 00 85 D1 00 03 DD 00 00 4D 00
00 00 00 Line:349
00 1A B8 00 00 20 00 85 D1 B0 00 07 04 00 85 D1 00 03 DE 00 00 4E 57
00 00 00 Line:350
Click to expand...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Actual Size of UDP Packets 1
Udp server receives too much data 1
Socket.Available and UDP datagrams 2
Udp receive problem 2
flushing a socket buffer 4
Using UDP sockets with large chunks of data... is there...? 7
Monitoring incoming UDP packets 3
UDP Sockets - Get Remote Host on data RX 2

Top