Video file packets over UDP -- incremental read and stream

Question

I would like to transfer a video file read from disk to a receiver using UDP DatagramPacket in Java.

The key points are as follows: though the file to be transmitted is read from disk, I should assume that I'm not aware of the file size. The total file need to be read incrementally and the datagram packets of the file should be of varying sizes.

In short, I should assume that I'm streaming a live video to a receiver without knowing how much data I would totally need to send and at what rate the data will get generated.

Right now, I have a code which reads the file on the disk at once and convert into datagram packets to transmit using UDP socket. But I have no clue on how could I packetize the file without knowing the original file size and read incrementally that would mock the live streaming of a video.

Any inputs on to get this idea implemented using Java would be very useful. I need to implement a real time file transfer protocol once I get this basic thing working.

Sender:

        File file = new File("/crazy.mp4");
        FileInputStream fis = new FileInputStream(file);
        DatagramPacket pack;


        int size = 0;
        byte[] buffer = new byte[((int) file.length())];
        ByteBuffer bb = ByteBuffer.allocate(4);
        bb.order(ByteOrder.BIG_ENDIAN);

        while (true) {
            size = fis.read(buffer);                
            pack = new DatagramPacket(buffer, buffer.length, address,
                    packet.getPort());
            socket.send(pack);
        }

Receiver:

     File file = new File("/crazyRecv.mp4");
     FileOutputStream fos = new FileOutputStream(file);  
     DatagramPacket rpacket = new DatagramPacket(buffer, buffer.length);

        while (true) {
            socket.receive(rpacket);
            fos.write(rpacket.getData(), 0, rpacket.getLength());
        }

Thanks.

@Shivan: Please check the edited version of question with code snippet — arun, Apr 11 '13 at 04:41

shazin · Answer 1 · 2013-04-11T05:32:55.400

2

This code of sending and receiving UDP packets can not guarantee to successfully recreate the file in client side.

UDP is Unreliable - There is no low level acknowledgement and packet retransmission mechanism like in TCP so you have to implement this. Packets may be lost and never received at client side
UDP is not sequential - You can not just expect the UDP packets to recieve at client end sequentially. First packet may arrive last and last packet first, subsequently corrupting the file. TCP guarantees sequential delivery.

You have to write your own Application Level protocol, if you still want to use. For Example

You send a packet with content "File Start"
The client sends an ack packet for that "File Start : Received"
If you didn't receive "File Start : Received" then you have to go to step 1
And then send packets with an Unique id "Packet 1 " + packet data
The client sends an ack packet for that "Packet 1 : Received"
If you didn't receive "Packet 1 : Received" then you have to go to step 4
Do step 4 - 6 for all packets
You send a packet with content "File End"
The client sends an ack packet for that "File End: Received"
If you didn't receive "File End : Received" then you have to go to step 8

edited Apr 11 '13 at 05:32

answered Apr 11 '13 at 05:27

shazin

21,379
3
54
71

Yeah, I'm aware that UDP is unreliable transport layer protocol. I plan to write a reliable file transfer protocol over UDP once I get this packetization thing working. My file transfer protocol allows retransmission of lost packets. Any inputs on packetizing the file with the requirements I mentioned would be of great help. – arun Apr 11 '13 at 05:47
Well Sending a Start and End File packet enables to mark the beginning and end. So now do you need to know how long the file is beforehand? – shazin Apr 11 '13 at 05:49
I could not predict the file length upfront because of the following requirement(even though I read file from the disk): I should assume that I'm streaming a live video to a receiver without knowing how much data I would totally need to send and at what rate the data will get generated – arun Apr 11 '13 at 05:52
Well Start and End packets eliminates the need to know the length at the beginning. When you get the Streaming you send a start followed by packets and when you don't receive Streaming anymore you can send End so that the client can finalize the File. – shazin Apr 11 '13 at 05:58

Video file packets over UDP -- incremental read and stream

1 Answers1