0

I need to implement a Peer To Peer File Transfer.

What protocol should I use? TCP or UDP? And why?

jweyrich
  • 31,198
  • 5
  • 66
  • 97
Caffeinated Coder
  • 670
  • 1
  • 8
  • 24
  • Without knowing your requirements, all we could do is guess. – David Schwartz Jan 06 '12 at 07:17
  • I am making an application for Android and Windows for Chat and File Sharing where the users can send files to each other.
    – Caffeinated Coder Jan 06 '12 at 07:22
  • Directly? Or through a server? Do you plan to handle the case where they're both behind NAT? Again, we need to know your requirements. – David Schwartz Jan 06 '12 at 07:27
  • and i plan to implement inter-lan calling over wifi, for that i would have to use UDP right? – Caffeinated Coder Jan 06 '12 at 07:27
  • 1
    @DavidSchwartz yeah, the communication would be direct as it is going to be a peer to peer network over wifi. – Caffeinated Coder Jan 06 '12 at 07:28
  • 2
    If you need NAT traversal in typical mobile situations, you need to use UDP. (But honestly, if you have to ask whether you should use TCP or UDP, the odds of you getting UDP right are very low.) You have to do all the things TCP does by yourself, and that's hard and tedious. – David Schwartz Jan 06 '12 at 07:29
  • I wont need NAT, all mobile devices would recognize other devices over the network connected to the routers. But going by the comments and answers I think I'll move forward researching on TCP. – Caffeinated Coder Jan 06 '12 at 07:50

5 Answers5

3

TCP is generically the best way to go when you want to ensure that your data gets to its intended destination with appropriate integrity.

In your case I would personnally choose tcp, because you will probably end up reimplementing tcp in some form inside of your udp packets otherwise (ask for block (syn), answer: i have block (syn ack), ok send it to me (ack)...data: (push ack)... ok done: (rst))

Also generically speaking, udp is the way to go when you want to broadcast, and you dont really care if the data gets there or not, meaning there is either high redundancy or low importance/integrity... since files require high integrity, it doesn't make a lot of sense to go UDP, again, unless you want to go through the extra work.

The only upside to udp would be the fact that is stateless, which could have some good implementations in a file sharing program.

Bottom line... go with your heart...

Ryan
  • 2,755
  • 16
  • 30
1

I'd recommend using TCP.

If you use UDP then you end up having to design and implement flow control and detection / retransmission of lost packets in your application-level protocol. Doing this in a way that gives you decent performance in good and bad networking conditions is hard work. For simple peer to peer, the payoff is generally not worth the effort.

FOLLOWUP

You ask:

and i plan to implement inter-lan calling over wifi, for that i would have to use UDP right?

Assuming that IP is implemented and the routing is set up correctly over your WiFi network(s), both UDP and TCP should work just fine.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

UDP does not guarantee that the packets will be delivered, which is something that TCP does. Please take a look at this previous SO post which highlights the difference between these two protocols.

Community
  • 1
  • 1
npinti
  • 51,780
  • 5
  • 72
  • 96
0

TCP helps ensure that your packets are received by the client and should be your choice for a file transfer because you want the file to be reproducible on the other end exactly as it is sent.

You can implement the file transfer using UDP too, but you would have to write your own logic for ensuring that the contents of the file are assembled correctly.

Dr. Nitin Reddy Katkam
  • 874
  • 9
  • 9
0

Since most users really care that all of their data makes it to the remote target with consistency, TCP is your best bet since packet error handling is managed. UDP is typically better for applications where loss is acceptable (e.g. player position in games) or where retransmission is not an option (e.g. streaming audio/video).

More on streaming

In the streaming A/V case, the data is always shipped with some error correction bits to fix some large percentage of errors. The endpoint manages the extra time required to detect (and potentially correct) the errors by buffering the stream. Nevertheless, it's obviously a ton of work (on both sides) to make it all happen and probably isn't worth it for P2P file transfer.

Update 1: audio streaming comment

The constraints are really based on required throughput, latency, and bit error rate (BER). Since these are likely both mobile devices, possibly operating across two carriers cellular networks, I'd opt for UDP with very high error-correction capability for audio. Users will likely be more displeased with no audio versus slightly corrupted audio and greater latency. Nevertheless, I would still use TCP for file transfer.

Nick
  • 2,393
  • 13
  • 22
  • audio streaming is in future scope, but it is surely on the cards. What you were saying were all the protocol constraints, but data would be sent over UDP right. – Caffeinated Coder Jan 06 '12 at 07:47
  • Thank you so much for your help. For now I'll be going forward with file transfer using TCP. For the next phase I'll contact you again for Audio Streaming. Regards. – Caffeinated Coder Jan 06 '12 at 09:52