Traceroute is an application to trace the path from A to B. (A is your location and B is the server you want to trace).
The basic algorithm is as follows:
send UDP with TTL = 1
Server A1 received, and return ICMP packet to A because TTL is expired.
--> know first machine between. For example A1.
send UDP with TTL = 2
Server A1 received, and send this UDP to server A2.
Server A2 received, and return ICMP packet to A because TTL is expired
--> know second machine between. In this example is A2.
Do it until to B. we can track down: A -> A1 -> A2 -> ... ->B
I have a doubt that makes me skeptical as to whether this algorithm works correctly.
Since routing tables are updated frequently, during a traceroute, say for TTL=3, the probe packet follows the path A1->A2->A3->A4.
Now, when we send a probe packet with TTL=4, is it guaranteed to pass through A1, A2, A3, and A4 and then onto A5?
If not? Does the final output represent a valid path?
Hope someone can shed some light on this issue. Thanks a lot in advance!
Now, when we send a probe packet with TTL=4, is it guaranteed to pass
through A1, A2, A3, and A4 and then onto A5?
No, it's not guaranteed, but it is likely in most real-world cases. In cases in which the TTL=4 packet doesn't travel along the same path as the previous packets, you'd end up with a result that doesn't accurately reflect the actual network topology:
You can reduce the chance of this happening by using Paris Traceroute, which is a traceroute implementation that fiddles with various IP & ICMP header fields (article) to increase the chances for all packets to travel along the same path.
Related
In TCP protocol, is it possible for receiver to get packets with sequence numbers in this pattern?
oldest newest
| |
v v
1 , 2, 3, 1, 2, 3
Specifically, the interesting bit is that after receiver gets packet 3, the next packet it gets is with sequence number 1.
The case I am imagining here is that the sender sent packets 1,2,3 very fast. For some reason the receiver got those packets late and so could not ACK those 3 packets in time. This causes the sender to re-send the 1,2,3 packets again. This leads to the above sequence with the receiver seeing the pattern 1,2,3,1,2,3.
This is possible in TCP correct?
Sure. It's possible in TCP because it's possible in IP. IP packets can be received out of order, duplicated, or dropped. The three packets might be sitting in a router's buffer when the link between that router and its upstream router is severed. The upstream router might re-transmit those packets on another link not realizing the first router also delivered them.
IP doesn't provide any guarantees about delays, repetition, packet loss, or ordering. That's why TCP has to implement all those guarantees itself.
In TCP protocol, is it possible for receiver to get packets with sequence numbers in this pattern?
Depends on what you mean with receiver.
If you mean with receiver the system: yes, since at the network layer packets might be duplicated, reordered etc.
If you mean with receiver the application: no, since the systems TCP/IP stack will take care of the duplicates and reordering and pass only the original byte stream in the right order and without duplicates to the TCP socket of the application. Note that in this case the receiver does not even gets packets: it gets only the byte stream and the packet boundary used during transport is neither known nor relevant.
I was reading a book about computer network written by Tanenbaum specifically about handshaking. In there he explains two-way handshake is not enough, considering this case:
A wants to transfer money to B, so A sends a SYN to B, and then B sends an ACK to A. Connection is established and then A can send his money and then drop the connection after it's done. If there is a delayed duplicate SYN from A to B, B will send its ACK again and A will be transferring its money again.
That is one of the weakness of two-way handshake based on the book written by Tanenbaum if I understands it right. The book says three-way handshake can solve this problem.
With a delayed duplicate SYN from A, B sends an ACK and SYN which get rejected by A. This is where I don't get it, it's as if "Hey B why do you send me a SYN and ACK? Oh I know, this is from a delayed SYN, I should just drop it.". Why not, in two-way handshake, A doesn't know that the ACK is made by a delayed duplicate SYN?
Thanks.
To establish a connection, the three-way (or 3-step) handshake occurs:
SYN: The active open is performed by the client sending a SYN to the server. The client sets the segment's sequence number to a random value A.
SYN-ACK: In response, the server replies with a SYN-ACK. The acknowledgment number is set to one more than the received sequence number i.e. A+1, and the sequence number that the server chooses for the packet is another random number, B.
ACK: Finally, the client sends an ACK back to the server. The sequence number is set to the received acknowledgement value i.e. A+1, and the acknowledgement number is set to one more than the received sequence number i.e. B+1.
At this point, both the client and server have received an acknowledgment of the connection. The steps 1, 2 establish the connection parameter (sequence number) for one direction and it is acknowledged. The steps 2, 3 establish the connection parameter (sequence number) for the other direction and it is acknowledged. With these, a full-duplex communication is established.
According to Kurose and Ross's "Computer Networking: A top-down approach", 6th Edition, p. 232,
The first two segments carry no payload, that is, no application-layer data; the third of these segments may carry a payload. Because three segments are sent between the two hosts, this connection-establishment procedure is often referred to as a three-way handshake
In other words, A does not need to wait for the three-way handshake to complete before sending data. Only B needs to wait for the three-way handshake to complete.
And why does B need to wait? As S. Richmond says, B needs to know that A has received its sequence number before it starts sending data.
The three-way handshake is necessary because both parties need to synchronize their segment sequence numbers used during their transmission.
So, they(in turn) send a SYN segment with a sequence number set to a value n, which then is acknowledged by the other party via a ACK segment with a sequence number set to n+1.
Suppose that client does not send ACK(case of 2 way handshake). Now there might exist a case where seq number of client is not synchronized, but the server will assume that it is synchronized. This could cause a problem.
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 :)
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.
Say our client is sending the packets at a constant rate. Now, if server goes down temporarily there can be two situations
(We are using the TCP protocol)
1) The packet won't be delivered to the server. Consequently, the other packets in the line have to wait for the server to respond. And the communication can be carried out from there.
2) The packet won't be delivered and will be tried again, but the other packages won't be affected by this packet.
Say, packets A, B and C are to be transferred. While I am sending packet A the server goes down temporarily, then the packets B and C will be sent at the time they were initially scheduled to be or they will be sent once A is received by the server.
TCP is a stream-oriented protocol. This means that if, on a single TCP connection, you send A followed by B then the reciever will never see B until after it has seen A.
If you send A and B over separate TCP connections, then it is possible for B to arrive before A.
When you say "goes down temporarily", what do you mean? I can see two different scenarios.
Scenario 1: The connection between Server and Client is interrupted.
Packet A is sent on its way. Unfortunately, as it is winding its ways through he cables, one cable breaks and A is lost. Meanwhile, depending on the exact state of the TCP windowing algorithm, packets B and C may or may not be sent (as that would depend on the window size, the size of A/B7C and the amount of as-yet unacknowledged bytes sent). I guess that is saying both your "1" and "2" may be right?
If B and/or C have been sent, there will be no ack of A, until it has been resent. If they have been sent, once A has arrived, the server will ack up until the end of the last frame received in sequence (so, C, if taht is the case).
Scenario 2: The sever goes down
If this happens, all TCP state will be lost and connections will have to be re-established after the server has finished rebooting.