UDP Multicast losing messages

[DaTurk]

Hi,

I'm trying to send a large number of messages to a UDP multicast group
with which I have one client subscribed. But I'm losing mesages, and
I'm not entirely sure why. I can't seem to find the reason, the asynch
receive on the client doesn't even get called the corect number of
times, which is 1000. I'm trying to send 1000 messages via an asynch
call to sendto.

the connect code for the send

lock (_lock)
{
if (_socketState ==
TSMultiCastEndPointState.Connected) return true;

_socket = null;
_socket = new Socket(AddressFamily.InterNetwork,
SocketType.Dgram, ProtocolType.Udp);
_remoteEP = new IPEndPoint(_remoteIP, _port);
_localEP = new IPEndPoint(_localIP, _port);

_socket.SetSocketOption(SocketOptionLevel.Socket,
SocketOptionName.ReuseAddress, 1);

_socket.Bind(_localEP);

connectSuccessful = true;

_socketState = TSMultiCastEndPointState.Connected;
}

other then that I just call sendTo 1000 times in a for loop, and the
receive on the client only pops maybe 300 times. Anyone have any
ideas? The receiveCallback code won't really help because it doesn't
even get called 1000 times.

 

[Peter Duniho]

Hi,

I'm trying to send a large number of messages to a UDP multicast group
with which I have one client subscribed. But I'm losing mesages, and
I'm not entirely sure why.

UDP is not reliable. There is no guarantee that if you send 1000 datagrams,
each recipient will receive 1000 datagrams.

There's a bunch of other stuff UDP doesn't guarantee either. You really
need to study the basic rules for UDP before you start trying to use it.

 

[Samuel R. Neff]

Losing 70% of packets is a huge number, especially within a local lan
(I'm assuming OP is in a development environment within a local lan).

Sam


------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

 

[DaTurk]

UDP is not reliable. There is no guarantee that if you send 1000 datagrams,
each recipient will receive 1000 datagrams.

There's a bunch of other stuff UDP doesn't guarantee either. You really
need to study the basic rules for UDP before you start trying to use it.

I do understand UDP. Been using it for years, but like Mr. Neff said
losing 70% is a very large percentage. THere has to be something else
going on.

I've tried running the sender / receiver on the same box, and on
different boxs, but with the same results. It seems that it can do 100
messages fine, but anything larger, say 125 encounters some loss. What
really worried me is that the Asynch receive callback is not even
receiving anything.

That's why I think it has something to do with the way the sockets have
been set up. I tried sending the messages synch, and asynch with the
only change being that using asynch, more message were received.

Does anyone have any other ideas besides condescending to me about UDP

 

[Peter Duniho]

Does anyone have any other ideas besides condescending to me about UDP

It's not condescension. It's simply being realistic. Too many people show
up here asking about sockets without really having made any effort to learn
the fundamentals to assume you are different when you're not clear about
your problem. You said "But I'm losing mesages, and
I'm not entirely sure why". Nothing in that statement suggests that you
have any idea that it's natural to lose messages while using UDP, and in
fact it strongly suggests otherwise.

I agree that 70% is a large number to lose, but it's not impossible. That
said, sure...you might have a bug in your own code. Since you're so
experienced with UDP, you're obviously aware of the diagnostic tools that
you can use to narrow down where the data is being lost. That would be the
first thing I'd do...until you know where the problem is, you can't hope to
fix it.

In addition to ruling out actual network problems, you are also mistaken to
assume that the receive code itself isn't faulty. Failing to keep up with
the inbound data is one easy way to lose lots of UDP datagrams. At this
point, you have not posted any information that narrows the problem down one
bit.

You either need to post *all* of the code involved and hope someone is
generous enough to read through it all and see if there's a bug, or you need
to do enough diagnostics to narrow the problem down enough so that you can
post the exact subset of the code that you *know* is causing the problem.

Pete

 

[DaTurk]

Wow, touchy touchy. Look, I have analyzed my traffic, and do see that
everything is getting sent across. Stating that "I'm not entirely sure
why" doesn't suggest I don't know how to use UDP. It suggests that I
don't know why I'm losing messages, and that's all. If you want to
assume that I'm daft, that's your choice. At any rate, I've found my
problem, but I do appreciate your help. In the very least you've
helped me to become a better person.

 

[Peter Duniho]

Wow, touchy touchy.

I'm not touchy. I'm simply trying to explain why YOU shouldn't be touchy.
Who told you to assume I was being condescending? I didn't (and even if I
did, why should you listen to me?).

Look, I have analyzed my traffic, and do see that
everything is getting sent across.

So it *is* a problem with your receiving code, even though you said you knew
it wasn't.

Stating that "I'm not entirely sure
why" doesn't suggest I don't know how to use UDP. It suggests that I
don't know why I'm losing messages, and that's all.

The most common reason for someone to not know why they are losing UDP
datagrams is that they don't understand UDP. You didn't write anything to
suggest otherwise, so the safe assumption was that you don't understand UDP.
If you do, that's great. But you didn't write anything to start with to
suggest you do, and you *did* write something that suggested you don't.

Again, I had no control over what you wrote in your initial post (or any
subsequent one for that matter). I can't help that your post was ambiguous
and led to incorrect assumptions. When you provide incomplete information,
we are forced to either make assumptions or simply not answer. I suppose
not answering is a valid option, but it doesn't make for much forward
progress. Personally, I prefer to make assumptions and try to get a problem
solved in the process.

If you want to
assume that I'm daft, that's your choice.

I prefer the word "inexperienced". Many people fail to understand UDP
without being "daft". But again, if you want to be touchy about it, I
suppose that's your right. Just remember, it's *you* being touchy, not me.

At any rate, I've found my
problem, but I do appreciate your help. In the very least you've
helped me to become a better person.

If you found your problem, why did you not post the resolution here?
There's more to having a newsgroup than just getting people to tell you what
your problems are. By sharing your solution, you may help someone with the
same problem in the future.

Pete

 

[DaTurk]

Your right, my apologies. I was wrong in assuming the problem was not
in the receive method. I assumed that because the method wasn't being
hit there was an issue ealier on.

SO the problem was that the Receive method wasn't reacting quick enough
I was using several libraries that I built previously to deal with TCP.
They would have worked fine, but they needed to be stream lined a bit
more to be viable in a UDP world. SO I'm in the process of optimizing
them now. Specifically, my method to detach my header from the front
of the byte array was a bit more cumbersome then it needed to be. I
was truncating the front of the received byte array, and manually
deserializing it to get the info in the header.

WHich is quick, but the truncating of the original byte array had alot
of overhead as it created new memory twice, once for the header byte
array, and a second time for the newly truncated original message. Now
it passes the original byte array to the Header struct to be
deserialized, but isn't truncated. The header struct just bitConverts
what it needs.

And Peter, even though you may not mean too, you come off
condescending.