Send large data via UDP / Split QByteArry by size?

soroush

Hi

I need to send and receive very large data using QUdpSocket. Unfortunately udp provides 8192 bytes per diagram, so there is need to divide data into smaller pieces.

There is a QByteArray with length of 921600. I want to send 8192 bytes each time. What is the fast way to split a QByteArray by size?

fluca1978

Would a cycle where using "left":http://doc.qt.nokia.com/latest/qbytearray.html#left and "remove":http://doc.qt.nokia.com/latest/qbytearray.html#remove do the work?

andre

Note that you would need to create a bit of a protocol for this. Your data chunks send by UDP may or may not arrive, and may arrive in any order. From the top of my head, they are even allowed to be delivered more than once. That is the downside of using UDP over using TCP.

That means that your receiving application will need to be able to re-assemble the messages, so it needs to know what is contained in each of the messages. I think that you need to add a small header to the datagram that gives some image number (take care that it will overflow back to 0 or some negative number at some point!), the piece number and the number of pieces for this image. Your receiver can then decide what to do with the datagrams it receives, and should be able to reconstruct the image (as long as it receives all the pieces, that is). Because the first piece of image 2 may arrive before the last piece of image 1, you should allow to at least reconstruct two images at a time.

Alternatively, switch to using TCP.

soroush

Ok I do this:
Server side

send start code that is an array of 16 bytes, they are all 0xFF
split images by row
send each row over UDP
send finish code (16 x 0x00)
Client side:
wait until see start code
if there is finish code on port, display image
else collect data and append to image data.

This doesn't work properly.... Final image is always distroyed or disformed... i'm going to switch everything to TCP

goetz

Of course it is not guaranteed to work. Andre already told you the limitations of UDP data transfer, like unordered reception or loss of datagrams and mixing of data of different images. TCP really seems the superior protocol here.

andre

Actually, in principle UDP is much more suitable for this application. You don't want to halt a whole video stream just because you missed a single frame. However, it does take some work to get it to work...

On a sidenote: it looks like you want to send an uncompressed stream of images. If we add network overhead to your image size, you are trying to send about 1MB per frame. To make that into streaming video, you end up with about 24MB/s raw network speed. I hope you realize you need a Gbit network to get that throughput? 100Mbit is not enough for such a data rate.