i am developing a peer to peer file transfer application using java. I want to transfer files in a faster and effectient way. I have an idea of using UDP instead of TCP for file transfer. If i use TCP, header information might be a overhead and it slows down the transfer. For TCP mode of reliable transfer, each packet need to be acknowledged and unnecessary timeouts need to be maintained. Also connection need to be established before hand, which restricts the packets flow through a particular channel, which in some time gets congested and slows the transfer drastically. In UDP mode, packets travel in different route which wouldn't congest a particular traffic. We can send more data contents since header information are unnecessary. The problem with this technique is reliability since every byte in file is very important and a packet loss can't to detected. I am thinking of using a very little amount of header information to provide reliability. I would like to send duplicates(maybe 3-6) of each packet to ensure atleast one reaches the destination correctly. There is very less probability that all gets corrupted, since each duplicate packet travels in different route. But if two of the duplicates(one being corrupted and the other in right format) reaches the destination, the destination as to decide on which one to discard. For that purpose, I have to use another header information. Can anyone tell me what other problems we encounter in this mode of transfer. Awaiting for lot of suggestions.
Originally posted by Balaji Jayaraman: [...] Also [TCP] connection need to be established before hand, which restricts the packets flow through a particular channel [...]
I didn't think TCP constrained you to a specific route -- but I'm happy to be corrected on this.
The problem with [UDP] is reliability since every byte in file is very important and a packet loss can't to detected. I am thinking of using a very little amount of header information to provide reliability. I would like to send duplicates(maybe 3-6) of each packet to ensure atleast one reaches the destination correctly.
Aren't you concerned that sending six copies of each packet will degrade performance to levels well below those of a TCP connection? I know TCP/IP has its overheads, but they're not that bad. And besides, no matter how many copies you send, there is still a chance that none of them will arrive. This is simply the wrong way to go about it. What you want to do is basically duplicate the work of the TCP protocol, but at an application-specific, much coarser-grained level so you get none of the overheads. You'd first indicate what you want to transfer, how large, etc; then you'd pump out the packets with the data, and the receiving side would sort out what it'd got, confirm receipts and ask for re-sends of lost packets. Something like that. Your gain would be that you can probably send acknowledgements and re-send requests for lots of packets at once. Corruption shouldn't be too much of a problem, I think. UDP packets are protected by a CRC. It'd probably a good idea to calculate a CRC or MD5 of the entire data set and check that afterwards. - Peter
And then the flying monkeys attacked. My only defense was this tiny ad: