Introduction to the

Recently, I optimized the interface and experience of a P2P file transfer demo I wrote before. Only one party needs to input the 6-digit UUID of the other party to establish a connection, and then you can select the file to send. Here is the experience link:

peer.codeasily.net

Using the step

  1. Zhang SAN wanted to send a small video to Li Si, but he was afraid of being checked by the water meter after uploading files through the Internet. Besides, Zhang SAN and Li Si were using different platform operating systems. At this time, they thought of the gadget peer.codeasily.net, so they opened it together.
  2. Zhang SAN told Li Si his UUID, Li Si input Zhang SAN’s UUID and Zhang SAN establish point-to-point connection;
  3. Li Si drags the video into the red area and clicks the “Send” button to Send it.
  4. The blue area on John’s side received the video from John, and soon it was over
  5. Finally, click “Download” to Download the video on your computer’s hard drive

Here are the reasons why Sam and Li used this tool:

  • The above scene if Zhang SAN Li Si is in the same local area network, the ideal situation can only through the local area network transmission of the file, the file content does not pass the Internet
  • File transfer is fragmented and transmitted as encrypted binary data
  • Other online communication tools are cumbersome to use (scanning code, waiting for advertisements, following public accounts, unstable transmission on the Internet, etc.)
  • A small video file is a file whose size cannot be too large. If the file size is too large, the transmission speed is slow. You are advised to use the file size smaller than 100 MB

Implementation logic

This tool is very easy to implement, but there are too many things to master (webRTC, STUN, TURN, P2P encryption, etc.), interested friends can jump to the end of the article reference learning ha.

Here is the flow chart:

To summarize the main points:

  • In the middle of the picture, the green cloud pointed by many arrows is the Websocket signaling server in my server, which is responsible for sending UUID, offer and ICEcandidate to each other at both ends. It is the “notary” used to establish P2P connection at both ends, so that both ends can know each other’s identity
  • In the figure, both PeerA and PeerB need their own UUID. When one party knows the UUID of the other party, it tells the signaling server the UUID of the connected party, and the signaling server tells the UUID of the connected party, so that the two parties know who to send the signaling to next
  • The followingRTCPeerConnection,createDataChannel,createOffer,setLocalDescription,onicdecandidate,setRemoteDescription,addiceCandidateThese are all WebRTC apis, which generate offer (for SDP media negotiation) and ICecandidate (for network negotiation) signaling respectively, and establish point-to-point connections after WebRTC negotiation
  • Once a P2P connection is established, it can pass throughDataChannelData channel to transfer file data to each other, my steps are as follows:
    • The arrayBuffer of the entire file is encrypted by MD5 to obtain the file hash for verifying the file after transmission
    • Then, the file is divided into blocks, and the file name, hash, total size, block number and other information are combined into a packet
    • Pass each packet into an arraybufferDataChannelTo the peer end, the packets are sent synchronously in a queue
    • After receiving the data packets from the sender, the peer end performs the preceding steps to reverse unpack the data packets. Finally, the peer end combines the data packets with the hash into a file and verifies whether the hash of the combined file is consistent
    • After receiving the packet, the peer end sends a message to inform the sender that it has received the packet. The received message contains only the packet number and no other content.
    • After receiving the received message, the sender can know the receiving status of the peer end and prompt the interface

This is the complete process of P2P file transfer

There is one point to mention here. The step above is that packets are sent synchronously one by one in the form of queue, which is obviously inefficient. In fact, I sent all packets at once in the form of asynchronous at the beginning. Therefore, packet loss may occur when I send several data packets in asynchronous mode at one time or in batches at the same time, which cannot be met in file transfer scenarios

So I decided to send in the form of queue synchronization one by one, so the transmission speed will be slow, but is not without other plan, maybe you can try to open several more channels to realize the parallel transmission, like open a multi-threaded, theoretically can reuse had consulted the SDP and icecandidate, but don’t know will also won’t be the packet loss, I’ll try it when I have time.

The resources

WebRTC implements P2P file transfer

P2P communication principle and implementation – Evilpan

P2P communication standard protocol STUN – EVilPAN

P2P communication standard protocol (II) turn-EVilPAN