Always wanted to write a cross-LAN chat and file transfer, as well as video chat software, the two days just idle nothing to write the code, the code has been uploaded to Github:https://github.com/vinllen/chat
In fact, before the idea of peer-to-peer mode, the peer must pass through NAT, now NAT has 4 modes:
- Full-cone NAT
- Restricted cone-type NAT
- Port-Limited conic NAT
- Symmetric NAT (bidirectional NAT)
Wikipedia gives the following definitions:
- 1.Full Cone NAT, aka one-to-one (one-to-one) NAT
Once an internal address (IADDR:PORT1) is mapped to an external address (EADDR:PORT2), all packets originating from Iaddr:port1 are sent out through Eaddr:port2. Any external host can reach Iaddr:port1 by sending the Eaddr:port2 to the contract.
- 2.address-restricted Cone NAT
Once an internal address (IADDR:PORT1) is mapped to an external address (EADDR:PORT2), all packets originating from Iaddr:port1 are sent out through Eaddr:port2. Any external host (Hostaddr:any) can be sent to Eaddr:port2 by the contract to reach Iaddr:port1 premise is: Iaddr:port1 before sending packets to Hostaddr:any. "Any" means that the port is not restricted
- 3.port-restricted Cone NAT
Similar to restricted cone NAT (Restricted cone NAT), but there are also port restrictions.
Once an internal address (IADDR:PORT1) is mapped to an external address (EADDR:PORT2), all packets originating from Iaddr:port1 are sent out through Eaddr:port2. An external host (HOSTADDR:PORT3) is able to send a packet to the IADDR:PORT1 if the package is sent to Hostaddr:port3 before Iaddr:port1.
- 4.Symmetric Nat (symmetric NAT)
Each request from the same internal IP and port, to a specific destination address and port, is mapped to a unique external IP address and port. Packets that have the same internal IP and port sent to different destinations and ports use different mappings
Only external hosts that have received an internal host envelope can send the packet back
For the 1th type is particularly simple, because the port exists mapping, as long as the packet sent to the network exit routing port, routing will help you forward
For the 2nd, 3 cases, you can use the following method (content from the blog: Click to open the link):
Suppose the network model is as follows:
Restrictive cone-NAT and Port-restrictive-cone-NAT (referred to as restrictive NAT), the penetration of a restrictive cone NAT discards its unknown source address to the internal host's packet. So if ClientA-1 now send UDP packets directly to ClientB-1, then the packets will be nat-b ruthlessly discarded. Therefore, the following method is used to establish communication between ClientA-1 and ClientB-1.
- 1. ClientA-1 (202.103.142.29:5000) sends a packet to the server, requesting and ClientB-1 (221.10.145.84:6000) communication.
- 2. Server sends the CLIENTA-1 address and Port (202.103.142.29:5000) to ClientB-1, telling ClientB-1 that ClientA-1 wants to communicate with it.
- 3. ClientB-1 sends a UDP packet to ClientA-1 (202.103.142.29:5000), of course, when the packet arrives at the NAT-A, it is discarded, which is not critical, because the UDP packet is sent only to let the Nat-b Remember the purpose of this communication address: port number, when the next time with this address and port as the source of data arrived at the time will not be discarded by nat-b, so on the nat-b on a hole from ClientB-1 to ClientA-1.
- 4. In order for ClientA-1 to know when to send data to ClientB-1, ClientB-1 sends a message to the server after punching the ClientA-1 (202.103.142.29:5000), telling the server It's ready for the job.
- 5. The Server sends a message to CLIENTA-1, the content is: ClientB-1 is ready, you can send a message to ClientB-1.
- 6. ClientA-1 sends UDP packets to ClientB-1. This packet will not be discarded by nat-b, and subsequent packets sent by ClientB-1 to ClientA-1 will not be discarded by ClientA-1, as Nat-a already knows that the first communication originated by ClientA-1. At this point, ClientA-1 and ClientB-1 can communicate.
For the 4th case, oh no, too hard, need to guess the port number (blog address: Click to open the link):The above discussion is how to penetrate the cone (Cone) NAT, symmetric NAT and cone NAT are very different. For symmetric NAT, symmetric NAT does not allocate the same port as a cone (Cone, full cone, restriction cone, port restriction cone) NAT when the host in a private network communicates with several different hosts outside. Instead, a new session is created and a port is reassigned. Refer to the procedure above to penetrate the restrictive cone NAT at step 3 o'clock: ClientB-1 (221.10.145.84:? When you punch a hole in the ClientA-1, symmetric NAT will reassign the ClientB-1 to a port number that is unknown to the server, ClientB-1, and ClientA-1. Similarly, ClientA-1 does not receive this message at all, and in step 4, ClientB-1 sends the notification message to the server, ClientB-1 's socket is still (221.10.145.84:6000). Also, NAT-1 will also reassign the port number to ClientA-1 at step 6 o'clock: ClientA-1 sends the packet to what it knows but the wrong ClientB-1. Therefore, the chances of penetrating a symmetric nat are small. Here are two strategies that are likely to penetrate symmetric NAT.
1. Simultaneous open TCP (simultaneous TCP open) policy
If a symmetric NAT receives a TCP SYN packet from outside the local private network, the packet wants to initiate a "ingest" TCP connection, in general, the NAT rejects the connection request and discards the SYN packet, or sends back a TCP RST (Connection reset, rebuilding the connection) package to the requester. However, there is a situation where this "ingest" connection is accepted.
The RFC stipulates that for symmetric NAT, when the source IP address in this received SYN packet: port, Destination IP address: Port matches the address information in an activated TCP session registered with NAT, Nat will release the SYN packet. What needs to be pointed out is: What is a TCP connection that is already active? In addition to the TCP connection that is actually established, the RFC specification states that if NAT happens to see a SYN packet that has just been sent and the address in the SYN packet it receives: The port information matches, then NAT will assume that the TCP connection has been stimulated And will allow the SYN packet in this direction to enter the NAT inside. At the same time open TCP policy is to use this time to establish a connection.
If client A-1 and client B-1 are able to correctly predict each other's NAT will give the next TCP connection a public TCP port assigned, and two clients can simultaneously initiate an "out-of-Office" T The CP connection request, and before the other's SYN packet arrives, the SYN packet that you just sent out can pass through own NAT, the end-to-end TCP connection can be established successfully.
2.UDP Port guessing strategy
While the open TCP policy relies heavily on guessing the other side's next port, and relies heavily on the timing of sending connection requests, and the uncertainty of the network, the chance to build is small, even if the server acts as a synchronous clock. Here is a way to penetrate through UDP, because UDP does not need to establish a connection, so there is no need to consider the "open at the same time" problem.
To introduce ClientB-1 's tricks, first introduce the stun protocol. The STUN (simple traversal of UDP Through NATs) protocol is a lightweight protocol used to probe a NAT-mapped address: port. STUN uses the C/s structure, it needs to detect its own NAT-translated address: The client of the port sends a request to the server, and the server returns the client-converted address: port.
Refer to Step 2 in section 4.2, through NAT, when ClientB-1 receives the message sent to it by the server, ClientB-1 opens 3 sockets. Socket-0 sends a request to stun Server, after receiving a reply, assume that it was converted to the address: port (221.10.145.84:600 5), socket-1 send a UDP packet to ClientA-1, socket-2 Once again, send the request to another stun Server, assuming that it has been converted to the address: port (221.10.145.84:60 20). In general, there are two strategies for symmetric NAT assignment ports, one in order and one for random allocation. If the symmetric NAT is used in order to increase the policy, then the ClientB-1 will receive two times the address: Port sent to the server, the server can notify ClientA-1 in this port range to guess just ClientB-1 sent to it socket-1 In the address after NAT mapping: Port, ClientA-1 is likely to successfully guess the port number within the hole validity period, thus successfully communicating with ClientB-1.
/************************************ Ornate Split Line **********************************************************/Most of the above content refer to Wikipedia and Chengweiv5 's blog, I also wrote the code, try to use the second way to penetrate the NAT of our school, the result is tragic, for several days of the problem also did not find out whether the code is the reason or NAT limit for the 4th reason? But the project cannot be so stranded. I adopted another curve to the salvation of the route, with the current QQ mode, with the relay server for message forwarding implementation. 1. First a server with a public network IP 2. After configuring the environment (such as iptables, etc.), put the server code server, run 3. After the client connects, it can send files and chat.That's all, it's that simple.The only thing to note is that when I send a file, I call the Sendfile system call, and the receiving file calls Pat Patterson's package function: using splice to receive the file, theoretically these two functions are directly in the kernel state file transfer, Instead of having to copy the data in the kernel state and the normal state, the time is reduced. I tested a bit, to a few m size of the file is not a problem, but looks like the file is too big to be transmitted, visual sendfile have size restrictions ... This will be changed later.The last point, originally also to achieve video transmission, my idea is to call the local camera with OpenCV, and then the picture by a fixed number of frames per second, according to file method transmission, and then on the end of the image stitching into a video. Later felt a bit of trouble, finally on the Internet a check, sure enough, I do the part is to re-build the life of the wheel, now directly have a ready file transfer protocol. This part is also waiting for time to be perfected later.Finally, if everyone has an idea, can communicate with me, learn to progress together
Linux sockets cross-LAN chat and file transfer
