UDP sending data, something i don´t quite understand

Question

Okay from my knowledge UDP works like this:

You have data you want to send, you say to the UDP client, hey send this data.

The UDP client then says, sure why not, and sends the data to the selected IP and Port.

If it get´s through or in the right order is another story, it have sent the data, you didn´t ask for anything else.

Now from this perspective, it´s pretty much impossible to send data and assemble it. for example, i have a 1mb image, and i send it.

So i send divide it in 60kb files (or something to fit the packages), and send them one by one from first to last.

So in theory, if all get´s added, the image should be exactly the same.

But, that theory breaks as there is no law that tells the packages if it can arrive faster or slower than another, so it may only be possible if you make some kind of wait timer, and hope for the best that the arrive in the order they are sent.

Anyway, what i want to understand is, why does this work:

   void Sending(object sender, NAudio.Wave.WaveInEventArgs e)
    {
        if (connect == true && MuteMic.Checked == false)
        {
            udpSend.Send(e.Buffer, e.BytesRecorded, otherPartyIP.Address.ToString(), 1500);
        }
    }

Recieving:

        while (connect == true)
        {
            byte[] byteData = udpReceive.Receive(ref remoteEP);
            waveProvider.AddSamples(byteData, 0, byteData.Length);
        }

So this is basically, it sends the audio buffer through udp.

The receiving par just adds the udp data received in a buffer and plays it.

Now, this works.

And i wonder.. why?

How can this work, how come the data is sent in the right order and added so it appears as a constant audio stream?

Cause if i would to this with an image, i would probably get all the data.

But they would be in a random order probably, and i can only solve that by marking packages and stuff like that. And then there is simply no reason for it, and TCP takes over.

So if someone can please explain this, i just don´t get it.

Here is a code example that is when sending an image, and well, it works. But it seems to work better when the entire byte array isn´t sent, meanign some part of the image is corrupted (not sure why, probably something to do with how the size of the byte array are).

Send:

                           using (var udpcap = new UdpClient(0))
                           {
                               udpcap.Client.SendBufferSize *= 16;
                               bsize = ms.Length;
                               var buff = new byte[7000];
                               int c = 0;
                               int size = 7000;
                               for (int i = 0; i < ms.Length; i += size)
                               {
                                   c = Math.Min(size, (int)ms.Length - i);
                                   Array.Copy(ms.GetBuffer(), i, buff, 0, c);
                                   udpcap.Send(buff, c, adress.Address.ToString(), 1700);
                               }

Receive:

                    using (var udpcap = new UdpClient(1700))
                    {
                        udpcap.Client.SendBufferSize *= 16;
                        var databyte = new byte[1619200];

                        int i = 0;
                        for (int q = 0; q < 11; ++q)
                        {
                            byte[] data = udpcap.Receive(ref adress);
                            Array.Copy(data, 0, databyte, i, data.Length);
                            i += data.Length;
                        }
                        var newImage = Image.FromStream(new MemoryStream(databyte));
                         gmp.DrawImage(newImage,0,0);
                        }

Answer 1

You should be using TCP. You write: it´s pretty much impossible to send data and assemble it. for example, i have a 1mb image, and i send it. So i send divide it in 60kb files (or something to fit the packages), and send them one by one from first to last. ... But, that theory breaks as there is no law that tells the packages if it can arrive faster or slower than another, so it may only be possible if you make some kind of wait timer, and hope for the best that the arrive in the order they are sent. That's exactly what TCP does: ensure that all the pieces of a stream of data are received in the order they were sent, with no omissions, duplications, or modifications. If you really want to re-implement that yourself, you should be reading RFC 793 - it talks at length about how to build a reliable data stream atop an unreliable packet service.

But really, just use TCP.

Answer 2

You're missing a lot of helpful details from your question, but based on the level of understanding presented I'll attempt to answer at a similar level:

You're absolutely right, in general the UDP protocol doesn't guarantee order of delivery or even delivery at all. Your local host is going to send the packets (i.e. parts of your request message) in the order it receives them from the sending application, and from there its up to network components to decide how your request gets delivered. In local networks however (within a handful of hops of the original requester) there aren't really a lot of directions for the packets to go. As such they will likely just flow in line and never see a hiccup.

On the greater internet however, there is likely a wide variety of routing choices available to each router between your requesting host and the destination. Every router along the way can make a choice on which direction parts of your message take. Assuming all paths are equal (which they aren't) and guaranteed reliability of every network segment between the 2 hosts its likely to see similar results as within network (with added latency). Unfortunately neither of the posed conditions can be considered reliable (different paths on the internet perform differently depending on client and server, and no single path on the internet should ever be considered to be reliable (that's why it's a "net").

These are of course based on general observations from my own experience in network support and admin roles. Members of other StackExchange sites may be able to provide better feedback.