Multicast large data size

Hi
I'm planning a network software and found the following problem:
I want to send packages via multicast from a qt application to another running on multiple clients. I understand the choice of multicast limits my protocol options to udp. I read in the documentation that it is disadvsed to send packages larger than 512 Bytes, but after making some calculations I estimated that some of my packages will have sizes around 800-1000 bytes and if I understand the documentation correctly this may cause fragmentation of the udp packages. Fragmentation may then cause data loss.
Does anyone have experience on how to send datagrams via udp larger that 512 bytes? Will I need to further fragment my data to avoid the problem or is there a way to correctly read the received datagrams even if they are fragmented?

Thanks four your advice

UDP can always lose packets, that's the whole point of a connection less protocol (no retransmits).
Whether or not your datagrams might become fragmented does not change a lot, an unfragmented packet can be lost or recieved out of sequence just the same.

The 512 bytes recommendation is for transmission in a local Ethernet LAN, which usually uses that size as MTU.
If you transmit outside your local network, it becomes less meaningful.

Cheers,
_

Hi, you didn't provide much info for your use case for multicast... Are you doing this over a local area network or the internet? Either way, the router infrastructure between your program sending multicast packets and the clients must have multicast enabled at each hop.

In a LAN environment, you have a good chance of that controlling that outcome, but in the wilderness that is the internet, you may find that one or more of your clients is unreachable due to a router along the network path that does not have multicast enabled.

Have you started coding anything yet?

Hi
Thx for your answer (and sorry for the delay). Yes the intended network to use is a local LAN (Actually a WiFi if possible), but I think I should clarify where I have problems in understanding the fragmentation.

Say I send relatively large data packets (~8Kb) using UDP (multicast) named {A, B, C, D}.
As mentioned by anda_skoa the order may not be guaranteed, so on the receiving end it might look like {D,B,A,C} or packet loss may occur so {D,B,C} could be what the client obtains. Therefore whenever my receivers UDP socket emits the readyRead() signal I will have to determine if the data I have is packet A,B,C, or D. These two scenarios are no problem for me to handle as the type of data I'm sending and the application permit for packets to be lost. The point about fragmentation that I don't understand is the following:

Lets say the large packages above are randomly fragmented (invisible to me as far as is I understand the Qt doc) as {A=(a1,a2,a3,a4),B=(b1,b2),C,D=(d1,d2,d3)}.
In this case when I get the readyRead() signal what do I obtain when calling readDatagram()? do I still get a combination of {A,B,C,D} (again a entire package may be dropped) or do I get the fragments and actually get packages like for example {a1,b2,a2,a3,a4,b1,d1,C,d2} ?.

In other words: if I obtain the readyRead() signal will I alway's obtain the full package that I sent? To me it is not as important to get all the packages, neither to get them in sequence but it is vital that I always get the entire package from the socket.

I know this is a very basic question, but again when it comes to networking i'm still quite a newbie.

Thx for your time.

Quote:

---

Originally Posted by bon_scott

Lets say the large packages above are randomly fragmented (invisible to me as far as is I understand the Qt doc) as {A=(a1,a2,a3,a4),B=(b1,b2),C,D=(d1,d2,d3)}.
In this case when I get the readyRead() signal what do I obtain when calling readDatagram()? do I still get a combination of {A,B,C,D} (again a entire package may be dropped) or do I get the fragments and actually get packages like for example {a1,b2,a2,a3,a4,b1,d1,C,d2} ?.

In other words: if I obtain the readyRead() signal will I alway's obtain the full package that I sent? To me it is not as important to get all the packages, neither to get them in sequence but it is vital that I always get the entire package from the socket.

---

Here's what I think would happen. I say "think" because I don't have a lot of practical UDP programming experience. Too much trouble compared to TCP/IP, but I understand your multi-cast requirement has you married to UDP... :)

Your app sends A, B, C, and D. The IP layer will fragment your payload into multiple packets (if required) based on the path MTU between your app and the multi-cast clients. Using A as an example, if a2 is lost, then the receiver's IP layer will not be able to reassemble the payload, nor will it be retransmitted, so the entire A payload is effectively lost. Based on that, I do not believe the IP layer would present any of a1,a3,a4 to your application, therefore readyRead() should not be signaled for any partial payloads.

Even if you only receive the full payload when none of the fragments are lost, they may still arrive out of order (BACD) or be duplicated (ABACD), or of course missing altogether.

Lastly, each readyRead() means there is data that is ready to be read from the socket. It does *not* mean that you have an even multiple of your payload. i.e. First readyRead() you may get all of A and part of B, etc. The next readyRead() will have the rest of B and whatever's next, etc. So, you'll want to append the data you readyRead() into a QByteArray or similar, so that you're always appending data read from the socket to your buffer and after each readyRead(), pick off the complete payloads from the start of the buffer and remove from buffer, etc.

It's commonplace to start your payload with an eye catcher, so you know if it's A, B, C, or D as well as the length (32-bit int) of the payload so that you can determine when you have received a full payload, etc. If you wanted to get fancy, you could even compute a checksum for your payload and send that along with the eye catcher and payload length fields.

Hope that helps and if anyone else has different thoughts regarding handling UDP, I'm all ears. I'd be interested to hear back from you once you start writing some code to share your findings, etc.

Good luck,

Jeff

Thanks this helps me alot.

Quote:

---

Lastly, each readyRead() means there is data that is ready to be read from the socket. It does *not* mean that you have an even multiple of your payload. i.e. First readyRead() you may get all of A and part of B, etc. The next readyRead() will have the rest of B and whatever's next, etc. So, you'll want to append the data you readyRead() into a QByteArray or similar, so that you're always appending data read from the socket to your buffer and after each readyRead(), pick off the complete payloads from the start of the buffer and remove from buffer, etc.

---

This is something i didn't think of, luckily I already added a eyeCharacter to every package I'm sending, and I add the size where necessary so i guess this should work already, most of the packages have a fixed size anyway.

As jefftee said, the readyRead() signal indicates availability of data. It could be emitted for one byte only or several datagrams as one.

He is also right that fragmentation on any layer below UDP will not show as such on the UDP layer, i.e. no partial datagrams will ever be delivered by the OS.

Cheers,
_

OK, I was curious so I wrote a small multi-cast server and multi-cast client to prove out what I suspected would occur for your use case. The attached code exhibits the behavior I described in a prior post and demonstrates the out of sequence and lost UDP datagrams and confirms that you will never receive partial datagrams that may have been fragmented and one or more fragments are lost.

Code isn't pretty, but demonstrates how to receive the datagrams and bust them out into individual payloads. The server multi-casts 10,000 datagrams with rotating through an eye catcher of A,B,C,D. The datagrams are random sizes from 512 bytes to 8K in size. I added the eye catcher, a sequence number generated by the server, the length of the payload, and a payload of all binary zeroes.

You can compare the packet type, sequence, and length from the server to the order received by the client(s).

Start one or more clients first, then start the server. Give this a try and let me know if you have any questions.

The project file is attached to this post.

Thx for your input
I tried your application and found that the package loss was huge and the server failed to send a lot of the packages, I then converted the multicastServer to a QThread so I could use usleep and msleep between packages, and as expected one can improve package loss rates by modulating the sending times.

Cheers

I was intentionally blasting packets as quickly as I could to demonstrate the out of sequence and missing packets that can plague UDP. Real world applications will likely have some processing time between sending packets, so it may not be as big of an issue in a real world application, but as you have seen, adding delay between sending the UDP packets will improve reliability significantly.

Good luck with your application, would love to hear how you make out.

Later