I am trying to implement P2P with Hole Punching. Here is the flow:
Both Peers(P1,P2) will send 1 packet to server(S).
Server(S) replies back to both telling others IP:PORT
P1 and P2 receive this UDP packet knowing other's external/public ip:port.
P1,P2 start sending packet to other peers public IP:PORT.
Once peers receive other peer's packet, I assume the hole is punched and will give this socket to my Application.
I tested this on different routers, here is the outcome:
When P1 and P2 both are on non-symmetric-NAT (Full/Restricted cone),
I don't face any problem.
When P1=Non-Symmetric and P2=Symmetric:
-----router-1 (Symmetric-NAT) + router-2 (non-Symmtric) = Success
---- router-3 (Symmetric-NAT) + router-2 (non-Symmtric) = *Failure*
Until 4th Step its fine. But in 5th step, no peer receives the packet of other peer. I was expecting that at-least *'peer behind non-Symmetric NAT' will receive the packet of other.*
Anybody has any idea whats happening?
There is a paper here
Basically they use two servers S1 and S2.
By looking at the outbound ports they are often able to predict what outbound port would be used when P1 sends a packet to P2 and vice versa.
Apparently many routers just use incrementing/decrementing or some skip size
There is no guarantee of predicting the correct port. They end up sending a bunch of packets to different ports hoping that one will get through.
I have a different idea how to approach it, I'll need to find a symmetric-NAT to test it out :)
Related
I have used google for the above questionair but I still couldn't find the answer for the above question. Please help me out on this.
Networking packets are quite a complicated subject, but I will try to explain them to the best of my ability.
Each packet has a source IP and a destination IP, and a body. That’s all it actually needs. Most packets also have a protocol. I don’t know every major protocol, but the basic ones are ICMP, TCP, and UDP(TCP and UDP might be built on ICMP, not sure). Tcp and UDP packets also have a source port and destination port. Using some Linux trickery, you can define your own protocol, but your router probably won’t know what to do with traffic coming in as it isn’t programmed to know whether it should let it in. TCP gives the illusion of a byte stream, but everything is still split into packets. ICMP is just a simple packet, used for pings and similar things. UDP is the most basic of the 3, and is similar to ICMP but with ports, as far as I can tell.
Back to TCP, it splits into multiple packets, because too large of packets are more likely to get lost. TCP also makes sure all packets arrive and in the right order. A stream is nessesary for this, as if you were to try to send your own packet, it wouldn’t have a check for how large, and could get lost very easily if not done right.
A UDP listener simply tells the OS to listen for UDP packets on that port instead of discarding them. When you send a UDP packet, the router remembers the source and destination, and allows the other end to communicate back for a certain length of time.
A TCP listener accepts packets requesting a UDP connection, and sends them to a different port. The router uses a similar strategy to UDP to know if a packet should be let in. Unfortunately, if one side terminates, there is no way for the other side or the router to know. Thus the router will often continue letting in packets to a stream that was closed, which could pose a risk.
This is my understanding, it is very much flawed. Hope I could help nonetheless!
When two devices D1 and D2(on different networks) have processes P1 and P2 running respectively on them then if P1 wants to get data from P2 then -
P1 establishes TCP connection with P2 .
P1 sends SYN packet.
P2 sends SYN-ACK packet.
P1 answers with ACK packet, concluding the three-way TCP connection establishment.
After this HTTP request is sent over this TCP connection.
Lets say D1 and D2 are on the same network, will this process be faster and why.
The less time it takes for P1's message to reach P2 and vice versa, the faster this process will be. That time depends on a variety of factors, among them is the physical distance between the machines and the number and capacity of networking equipment and links along the way.
Since machines in a local network are typically close, with little networking equipment between them, a connection between should faster than if the machines are further apart.
Of course one could imagine scenarios in which that's not the case, but those would be atypical edge cases.
I'm reading up on networking and there is something about the layer 2+3 OSI model interaction i don't get. I want first to understand the basics so feel free to keep it simple.
Lets say we have a LAN - 5 computers all connected to a router which is connected to an ISP router.
1.
one of the PC on the LAN wishes to send a message to another PC on the same LAN(they are both connected to the local router but not to each other directly) -
is there layer 3 encapsulation in use here?
if not - and we only use the layer 2 information, what is the path the message will go through? is it PC1->PC2 , or PC1->Router->PC2.
if it is going through the router - what information is added in each message transaction?
and if not - do PC's on the same LAN (connected to the same router in some layer 2 protocol) aware of each other? can they message each other although they are not connected directly
2.
one of the PC on the LAN wishes to send a message to a PC outside the LAN (way way outside).
i understand it goes PC1->Router->ISP Router -> ......... -> recipient local router -> recipient
which entity adds the layer 3 data? is it the router? PC1? ISP router?
when will this information be needed? since all single transaction is connected by devices who can talk between them self's in layer 2 protocols? (PC1 talks to it's router in level 2 protocol, so does Router to ISP router... etc?)
any further information worth adding will be appreciated.
Thanks!
Is there layer 3 encapsulation in use here? Yes it is! The two computers are connected in a network created by your router, which is a Network Layer Device. When the sender sends a packet it doesn't know where is the receiver (in LAN or in Internet), so it prepares to send the packet as usually. Then the router checks his table and knows that the receiver is connected with it, but until this happened everything was going on normally. So, the thing you have to understand is this: while it is a communication between two machines, all the protocols of each layer must be accomplished. If the computers would be connected with a switch, a Data Link Layer device, the authentication would be made with their MAC addresses instead of their IPs, so there is not a Network Layer here(obviously no layer 3 encapsulation ) but this is not your case.
That's a long story to tell how the packets travel from sender to receiver. But in general, there are two important information that each packet should have: the address of the destination machine(Network Layer), and an identifier of the process that should receive the packet in the destination machine (Transport Layer). If it is the first time that the machines communicate with each other, the router connected with the sender broadcasts that packet in all its outbound lines, and so on with the routers which receive this packet, until the destination is reached. After the first packet has been sent the routers keep records on their tables how to locate each machine in the best way possible. This will make broadcast unnecessary next times. So, the packet reached the destination. The receiver probably has a lot of processes opened in that time (open your Task Manager -> Processes to see what I'm talking about). This is where T.L protocols appear. They use the identifier in the head of the packet to address the packet in the right process. And than the communications goes on with Application Layer Protocols.
I hope that this is a useful information for you. If you really want to study this things I would suggest you Computer Networks of Andrew Tanenbaum.
If I understand OSI right - it's just an abstraction. http://en.wikipedia.org/wiki/OSI_model#Description_of_OSI_layers Your messages send in packets which is Transport layer. Those messages are built by means of Network layer. If there wasn't this layer packages data(information you send) wouldn't know how to encapsulate into a package.
if it is going through the router - what information is added in each message transaction
Each package consist service fields http://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure
Each time it passes throw a router, router adds information to a header (IP ...) to let the package receiver know where it came from ( it's network layer, because you don't add this information by yourself, it does network for you)
Using the TCP/IP protocol, given a connection between a client and a server, are the packets sent by the client to the server always received in the same order they were sent?
For example, if the client sends 3 packets of data, A, B and C, will the server always receive A first followed by B and C or is it possible for the server to receive C first, followed by A and B?
At IP level, packets may arrive in any order (if they arrive). At TCP level, the data stream is guaranteed to be ordered in the same manner on both ends.
That means yes, the server will always receive A then B then C. As long as you are using TCP.
When using TCP, data is received by the destination application in the same order as it is sent by the source application.
See the following for more details:
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Data_transfer
TCP is a transmission protocol, and it transmits data by sending the data out in IP packets over the underlying IP network. TCP is responsible for ensuring the correct transmission of the data, which includes ordering the arriving packets, re-requesting missing ones and discarding duplicates.
TCP as such does not expose any notion of "packet" to the user; the fact that the data is chunked into IP packets is a detail of the "over IP" implementation. A different implementation, e.g. TCP-over-bicycle-courier, might employ an entirely different scheme.
It cannot happen that you receive data in a different order on the application side over a TCP socket.
It may happen that packets are received in a different order by the networking layer of the OS, but TCP makes it a requirement that the upper levels get data in order. It is the OS' role to ask again for unreceived fragments etc and assemble these fragments. So, you need not worry.
UDP, on the other hand, offers no such guarantee.
The server (as the physical NIC of the machine) might receive them in any order. Your OS might receive them in any order again - that will mostly (but not allways) be the order of physical reception. Your client application is guaranteed to receive them in correct order, thats a property of TCP
In general, packets will be received in the same order they are transmitted. But the network may drop or reorder packets. For example, packets may take different routes and arrive out of order. Packets may be lost or even duplicated on the network. The TCP implementation is responsible for retransmitting packets that are lost, acknowledging packets that are received, ignoring duplicated packets, all with the objective of accurately reconstructing the transmitted byte stream at the receiver.
At the application level, you send a stream of bytes and receive a stream of bytes. TCP does whatever is needed to ensure the received stream of bytes is identical to the sent stream of bytes, regardless of what happens to the packets on the network.
Why is the IP called a connectionless protocol? If so, what is the connection-oriented protocol then?
Thanks.
Update - 1 - 20:21 2010/12/26
I think, to better answer my question, it would be better to explain what "connection" actually means, both physically and logically.
Update - 2 - 9:59 AM 2/1/2013
Based on all the answers below, I come to the feeling that the 'connection' mentioned here should be considered as a set of actions/arrangements/disciplines. Thus it's more an abstract concept rather than a concrete object.
Update - 3 - 11:35 AM 6/18/2015
Here's a more physical explanation:
IP protocol is connectionless in that all packets in IP network are routed independently, they may not necessarily go through the same route, while in a virtual circuit network which is connection oriented, all packets go through the same route. This single route is what 'virtual circuit' means.
With connection, because there's only 1 route, all data packets will arrive in the same order as they are sent out.
Without connection, it is not guaranteed all data packets will arrive
in the same order as they are sent out.
Update - 4 - 9:55 AM 2016/1/20/Wed
One of the characteristics of connection-oriented is that the packet order is preserved. TCP use a sequence number to achieve that but IP has no such facility. Thus TCP is connection-oriented while IP is connection-less.
The basic idea is pretty simple: with IP (on its own -- no TCP, UDP, etc.) you're just sending a packet of data. You simply send some data onto the net with a destination address, but that's it. By itself, IP gives:
no assurance that it'll be delivered
no way to find out if it was
nothing to let the destination know to expect a packet
much of anything else
All it does is specify a minimal packet format so you can get some data from one point to another (e.g., routers know the packet format, so they can look at the destination and send the packet on its next hop).
TCP is connection oriented. Establishing a connection means that at the beginning of a TCP conversation, it does a "three way handshake" so (in particular) the destination knows that a connection with the source has been established. It keeps track of that address internally, so it can/will/does expect more packets from it, and be able to send replies to (for example) acknowledge each packet it receives. The source and destination also cooperate to serial number all the packets for the acknowledgment scheme, so each end knows whether packets it sent were received at the other end. This doesn't involve much physically, but logically it involves allocating some memory on both ends. That includes memory for metadata like the next packet serial number to use, as well as payload data for possible re-transmission until the other side acknowledges receipt of that packet.
TCP/IP means "TCP over IP".
TCP
--
IP
TCP provides the "connection-oriented" logic, ordering and control
IP provides getting packets from A to B however it can: "connectionless"
Notes:
UDP is connection less but at the same level as TCP
Other protocols such as ICMP (used by ping) can run over IP but have nothing to do with TCP
Edit:
"connection-oriented" mean established end to end connection. For example, you pick up the telephone, call someone = you have a connection.
"connection-less" means "send it, see what happens". For example, sending a letter via snail mail.a
So IP gets your packets from A to B, maybe, in any order, not always eventually. TCP sorts them out, acknowledges them, requests a resends and provides the "connection"
Connectionless means that no effort is made to set up a dedicated end-to-end connection, While Connection-Oriented means that when devices communicate, they perform handshaking to set up an end-to-end connection.
IP is an example of the Connectionless protocols , in this kind of protocols you usually send informations in one direction, from source to destination without checking to see if the destination is still there, or if it is prepared to receive the information . Connectionless protocols (Like IP and UDP) are used for example with the Video Conferencing when you don't care if some packets are lost , while you have to use a Connection-Oriented protocol (Like TCP) when you send a File because you want to insure that all the packets are sent successfully (actually we use FTP to transfer Files). Edit :
In telecommunication and computing in
general, a connection is the
successful completion of necessary
arrangements so that two or more
parties (for example, people or
programs) can communicate at a long
distance. In this usage, the term has
a strong physical (hardware)
connotation although logical
(software) elements are usually
involved as well.
The physical connection is layer 1 of
the OSI model, and is the medium
through which the data is transfered.
i.e., cables
The logical connection is layer 3 of
the OSI model, and is the network
portion. Using the Internetwork
Protocol (IP), each host is assigned a
32 bit IP address. e.g. 192.168.1.1
TCP is the connection part of TCP/IP. IP's the addressing.
Or, as an analogy, IP is the address written on the envelope, TCP is the postal system which uses the address as part of the work of getting the envelope from point A to point B.
When two hosts want to communicate using connection oriented protocol, one of them must first initiate a connection and the other must accept it. Logically a connection is made between a port in one host and other port in the other host. Software in one host must perform a connect socket operation, and the other must perform an accept socket operation. Physically the initiator host sends a SYN packet, which contains all four connection identifying numbers (source IP, source port, destination IP, destination port). The other receives it and sends SYN-ACK, the initiator sends an ACK, then the connection are established. After the connection established, then the data could be transferred, in both directions.
In the other hand, connectionless protocol means that we don't need to establish connection to send data. It means the first packet being sent from one host to another could contain data payloads. Of course for upper layer protocols such as UDP, the recipient must be ready first, (e.g.) it must perform a listen udp socket operation.
The connectionless IP became foundation for TCP in the layer above
In TCP, at minimal 2x round trip times are required to send just one packet of data. That is : a->b for SYN, b->a for SYN-ACK, a->b for ACK with DATA, b->a for ACK. For flow rate control, Nagle's algorithm is applied here.
In UDP, only 0.5 round trip times are required : a->b with DATA. But be prepared that some packets could be silently lost and there is no flow control being done. Packets could be sent in the rate that are larger than the capability of the receiving system.
In my knowledge, every layer makes a fool of the one above it. The TCP gets an HTTP message from the Application layer and breaks it into packets. Lets call them data packets. The IP gets these packets one by one from TCP and throws it towards the destination; also, it collects an incoming packet and delivers it to TCP. Now, TCP after sending a packet, waits for an acknowledgement packet from the other side. If it comes, it says the above layer, hey, I have established a connection and now we can communicate! The whole communication process goes on between the TCP layers on both the sides sending and receiving different types of packets with each other (such as data packet, acknowledgement packet, synchronization packet , blah blah packet). It uses other tricks (all packet sending) to ensure the actual data packets to be delivered in ordered as they were broken and assembled. After assembling, it transfers them to the above application layer. That fool thinks that it has got an HTTP message in an established connection but in reality, just packets are being transferred.
I just came across this question today. It was bouncing around in my head all day and didn't make any sense. IP doesn't handle transport. Why would anyone even think of IP as connectionless or connection oriented? It is technically connectionless because it offers no reliability, no guaranteed delivery. But so is my toaster. My toaster offers no guaranteed delivery, so why not call aa toaster connectionless too?
In the end, I found out it's just some stupid title that someone somewhere attached to IP and it stuck, and now everyone calls IP connectionless and has no good reason for it.
Calling IP connectionless implies there is another layer 3 protocol that is connection oriented, but as far as I know, there isn't and it is just plain stupid to specify that IP is connectionless. MAC is connectionless. LLC is connectionless. But that is useless, technically correct info.