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.
Related
I have two machines M1, M2 on a network, with processes P1, P2 running on each of these machines. (The process is a C++-compiled executable, but perhaps that's not very significant.) These processes can also open, listen and connect on ports if necessary.
I want P1 to send a single string to P2 - not super-short nor super-long (say, 1 KB to 100 KB). The string is made up of printable ASCII characters, nothing extraordinary.
Now, I can have P2 keep an open a TCP port and listen on it, and P1 connect to it using TCP, send the message, and close the connection - and this will work.
My question is: Is there an formally-established, extremely-simple protocol that is basically just what I described? It would be much simpler than TFTP, for example.
Suppose we have 2 nodes, A and B, directly connected by Internet (we can ignore the underlyng network eg, routers, ISP etc).
We know RTT between nodes (80ms)
We know packet loss (0.1)
We know jitter (1ms)
We know bandwith, A=100/10mbps B=50/5mbps (first value is download, second is upload)
A sends a 1GB file to B by using the TCP protocol (with 64KB segment size).
How many times they need to exchange the file?
How many times it takes to do the same thing by using the UDP
protocol?
EDIT:
i guess the main difference in the calculation between UDP and TCP is that in TCP we need to wait for every packet to be sent before sending the next one. Or, in other words, we have to add in the delay calculation one RTT for every packet. Moreover, packetloss is not considered at all in UDP. I am not sure of what I'm sayng in this edit, so let me know if I'm wrong.
One of the major factors that affect TCP performance in 802.11 ad hoc networks is the unfairness in the MAC. Could someone please illustrate for me what this "unfairness" means?
In ad hoc networks, you usually are trying to do multihop routing. 802.11 CSMA/CA can manifest the "exposed terminal problem" in these situations. Consider a linear topology
... A <---> T <---> B ...
A and B are not in CSMA range. Suppose T is already transmitting a data stream to A. Now suppose a TCP stream starts getting routed through B. Because B CSMAs with A, it will essentially be locked out of the channel. The TCP connection being routed through B will eventually timeout.
Another possibility is the "hidden terminal problem". Consider the topology
A ---> X <--- B
A and B cannot CSMA. Suppose A and B each try to send a TCP stream to X. Because they cannot CSMA with each other, both win their respective channel contention rounds and transmit, only to have their frames collide at X. This can be solved to some extent with RTS/CTS. But in general, the reason for poor TCP performance in wireless environments has to do with the fact that TCP uses a dropped packet as a congestion signal, i.e., a TCP source will cut its window and there by drop its throughput. In wireless networks, dropped packets can be due to any number of transient things (e.g., collision, interference). A TCP source misinterprets these packet drops as a congestion signal and will throttle its send rate and underutilize the channel.
Another problem that can arise is due to the "capture effect". Again, consider
A ----> X <-------------B
Both A and B are in range of X, but B is farther away and thus has a lower received signal strength at X. Again, A and B cannot CSMA. In this case, X may "capture" the stronger transmitter A, i.e., its radio will decode A's frames but consider B's as noise (even though in the absence of A, X would go right ahead and decode B's frames). This sets up an unfair advantage for A if both are trying to route a TCP stream through X.
802.11's DCF also favors the last winner of the channel contention round. As a result, this gives a slight advantage to long-lived, bulk TCP transfers.
Note that all these problems affect all transport protocols, not just TCP. It's just that the way TCP is designed makes it react particularly poorly to these scenarios.
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 :)
Can a machine send n network messages/packets (to n destinations), simultaneously? Is there a upper bound on level of parallelism and what affects network's parallelism.
More specific, say there are 2 packets and four event, s1, r1 and s2, r2 denotes send/receive packet 1 and send/receive packet 2. When we send asynchronously (like s1, s2...r1,r2) and synchronously (s1...r1,s2...,r2), does it matter? Could total latency be shorten in the case of asynchronous send.
Yes, they can. A NIC just transmits the frames the driver tells it to, and does it as soon as it can. NICs don't care about destinations.
Higher layers (e.g: TCP) are responsible for retransmissions, and have their own buffering. NICs usually can have several frames ready to be sent, but they stay little time in the NIC, as soon as the medium is free, and the NIC has transmitted a frame without collisions, it can take another frame ready for transmission.
You basically have three choices:
Point to point
Multicast
Broadcast
A point to point message goes from one source to one destination.
A multicast message goes from the source, to the router, and from there gets distributed to the multiple recipients. There are some relatively intelligent switches (usually called "layer 2+" or something on that order) that can handle multicasting as well, but your average "garden variety" switch usually can't/won't handle it.
A broadcast goes from the source to everything else on the local subnet. There are a cople of ways this can be done. Probably the most common is to send to the address 255.255.255.255. Broadcasting is supported directly by Ethernet, which has a "broadcast" MAC address of FF:FF:FF:FF:FF:FF.
Note that IPv6 no longer supports broadcasting, but does have an "all hosts" multicast group that's vaguely similar.