Reputation: 1395
I am trying to make an application, which can send Files in chunks using DatagramSockets and DatagramPackets (I have to do it this way). The packets are encoded with other information (number of fragments, fragment index etc.) The problem I am facing:
I have a CustomThread running, which waits for a packet to arrive and then notifies a controller of its arrival through a MainNotifier object perviously passed to the CustomThread during its instantiation. The MainNotifier then processes it. The controller is the object that created and started the thread. Now my assumption here is that the processing functions in MainNotifier are still run on the CustomThread, because it called them, which probably results in a state where a packets arrival is not caught because the previous one is being handled. Would this be a correct assumption or is that completely wrong? If so how would I get around it? Would creating a separate thread for processing incoming packages inside the controller/MainNotifier relieve the CustomThread of the processing burden?
public void run(){
while (open){
byte[] buff = new byte[1472];
DatagramPacket packet = new DatagramPacket(buff, buff.length);
try {
socket.receive(packet);
mainNotifier.notifyReceivedMessage(packet);
} catch (IOException e) {
e.printStackTrace();
}
}
socket.close();
}
I am posting such a small snippet of code, because I believe my assumption is right and that the processing function of the packet is in this case not very important.
Upvotes: 1
Views: 1023
Reputation: 70909
not all packets containing File fragments are received by the other side
This is a design feature of UDP. You cannot expect all packets to be received, so you need to implement a policy in your code of either monitoring packet delivery or permitting packet loss.
Since you have a file (and missing pieces of it doesn't sound like a good thing) I believe you will need to monitor which packets have been received. How you do this can vary depending on your desired outcome; however, if you use TCP, it handles the re-transmission for you.
If you were attempting to beat the performance of TCP by shifting to UDP, keep in mind that part of the reason you get lower performance with TCP is because TCP tracks and redelivers the lost packets for you.
Upvotes: 3
Reputation: 108879
Yes, it is possible that data is filling lower level buffers faster than it is consumed and being dropped. Passing data onto a queue for processing by another thread may solve your immediate problem.
However, this is not the only way UDP traffic can be lost.
Your protocol has some similarities with TFTP in that files are transmitted in blocks over UDP. You may want to look at that protocol for inspiration with regards to retransmission.
I'm not suggesting you implement TFTP. The way it jumps ports and the server becomes the client is not nice.
Upvotes: 3