Say there are 2 nodes - A and B. Each of them maintains a state, which is a number in their memory. If A sends an increment somehow to B, then B will return 1. A sends an increment again, B will return 2. And so on. Same for B. And both A and B can update its state atomically.
For sending the increment, let's say B starts a TCP server to accept connections, and A is the client that establishes the connection with B. A can send increment to B through that established TCP connection.
Now, the question is: Can B also send increment to A through the same connection, and can A respond back with its own state through that connection?
Moreover, can A and B both send increments and respond to each other concurrently through the same connection? So that if A and B send increment simultaneously to each other, they can respond back with 1.
It’s an easy problem if A and B establish 2 connections - one for A as the client to send increment to B, and the other for A as the server to respond increment from B. And since there are 2 connections, A and B can send “increment” concurrently. But I wonder if it’s possible for A and B to exchange data with only one TCP connection? Does any protocol support this?
Yes, it's possible. A and B can both exchange data through the same connection. However, one of them will act as a server and the other as a client. In fact, even if A tries to connect to B and B to A at the same exact time, TCP is designed so that scenario results in only one connection. This situation is called simultaneous opening. Keep in mind that the classic concept of client and server don't exist per se in the TCP specs (they're just peers), although is intuitive and helpful to regard the peer that performs the active opening as a client and the one that perform the passive opening as a server.
As per data exchange, both can send increment messages to each other through the same connection. Check RFC 675 and RFC 793(The TCP reference) for more detailed in depth info.
Related
When connection sets up, there is:
Client ------SYN-----> Server
Client <---ACK/SYN---- Server ----①
Client ------ACK-----> Server
and when termination comes, there is:
Client ------FIN-----> Server
Client <-----ACK------ Server ----②
Client <-----FIN------ Server ----③
Client ------ACK-----> Server
my question is why ② and ③ can not set in the same package like ① which is ACK and SYN set in one package ???
After googling a lot, I recognized that the four-way is actually two pairs of two-way handshakes.
If termination is a REAL four-way actions, the 2 and 3 indeed can be set 1 at the same packet.
But this a two-phase work: the first phase (i.e. the first two-way handshake) is :
Client ------FIN-----> Server
Client <-----ACK------ Server
At this moment the client has been in FIN_WAIT_2 state waiting for a FIN from Server. As a bidirectional and full-duplex protocol, at present one direction has break down, no more data would be sent, but receiving still work, client has to wait for the other "half-duplex" to be terminated.
While the FIN from the Server was sent to Client, then Client response a ACK to terminate the connection.
Concluding note: the 2 and 3 can not merge into one package, because they belong to different states. But, if server has no more data or no data at all to be sent when received the FIN from client, it's ok to merge 2 and 3 in one package.
References:
http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm
http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm
http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm
I think of course the 2 and 3 can merge technically, but not flexible enough as not atomic.
The first FIN1 C to S means and only means: I would close on my way of communication.
The first ACK1 S to C means a response to FIN1. OK, I know your channel is disconnected but for my S(server) way connection, I'm not sure yet. Maybe my receiving buffer is not fully handled yet. The time I need is uncertain.
Thus 2 and 3 are not appropriate to merge. Only the server would have right to decide when his way of connection can be disconnected.
From Wikipedia - "It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK.[14]"
Source:
Wikipedia - https://en.wikipedia.org/wiki/Transmission_Control_Protocol
[14] - Tanenbaum, Andrew S. (2003-03-17). Computer Networks (Fourth ed.). Prentice Hall. ISBN 0-13-066102-3.
Based on this document, we can see the detail process of the four way handshake as follows
The ACK (marked as ②) is send by TCP stack automatically. And the next FIN (marked as ③) is controlled in application level by calling close socket API. Application has the control to terminate the connection. So in common case, we didn't merge this two packets into one.
In contrast, the ACK/SYN (marked as ①) is send by TCP stack automatically. In the TCP connection establishment stage, the process is straightforward and easier, so TCP stack handles this by default.
If this is observed from the angle of coding, it is more reasonable to have 4 way than 3 way although both are possible ways for use.
When a connection is to be terminated by one side, there are multiple possibilities or states that the peer may have. At least one is normal, one is on transmitting or receiving, one is in disconnected state somehow all of a sudden before this initiation.
The way of termination should take at least above three into consideration for they all have high probabilities to happen in real life.
So it becomes more natural to find out why based on above. If the peer is in offline state, then things are quite easy for client to infer the peer state by delving into the packet content captured in the procedure since the first ack msg could not be received from peer. But if the two messages are combined together, then it becomes much difficult for the client to know why the peer does not respond because not only offline state could lead to the packet missing but also the various exceptions in the procedure of processing in server side could make this happen. Not to mention the client needs to wait large amount of time until timeout. With the additional 1 message, the two problems could become more easier
to handle from client side.
The reason for it looks like coding because the information contained in the message is just like the log of code.
In the Three-Way Handshake (connection setup) : The server must acknowledge (ACK) the client's SYN and the server must also send its own SYN containing the initial sequence number for the data that the server will send on the connection.
That why the server sends its SYN and the ACK of the client's SYN in a single segment.
In connection Termination : it takes four segments to terminate a connection since a FIN and an ACK are required in each direction.
(2) means that The received FIN (first segment) is acknowledged (ACK) by TCP
(3) means that sometime later the application that received the end-of-file will close its socket. This causes its TCP to send a FIN.
And then the last segment will mean that The TCP on the system that receives this final FIN acknowledges (ACK) the FIN.
Imagine 2 machines A and B. A wants to make sure B receives a packet P even if there are network failures, how can that be achieved?
Scenario 1:
1) A sends P over the network to B.
Problem: if the network fails at step 1, B won't receive P and A won't know about it.
Scenario 2 with acknowledgement:
1) A sends P over the network to B.
2) B sends back ACK if it receives P.
Problem: If the network fails at step 2, A won't receive the ACK, so A can't reliably know whether B received P or not.
Having ACKs of ACKs would in turn push the problem 1 step further.
This is a huge problem which has been studied for years. Read about the TCP protocol which guarantees that either the data will be delivered or the sender will (eventually) know that delivery may have failed.
You can start reading here: https://en.wikipedia.org/wiki/Transmission_Control_Protocol
but there are many more helpful and interesting pages about TCP on the web.
Or you could just use TCP and take advantage of the work that has already been done.
I want to preface this by saying, I have a feeling that this idea will not work the way I'm imagining, but I'm not sure why. Its likely I'm making some sort of false assumption about the way the internet works.
Lets say server A has a file of size 1024 kb. This file is split up into 1024 packets to be sent over a network. Server A sends these 1024 packets to server B via TCP. As soon as B receives a packet it sends it back to A and vice versa. If any 3rd party C makes a request to A for the data, it would make a copy of each packet it receives from B and send to to C and B.
In this scheme, server A could delete its file once it has sent all the packets to B, freeing up disk space. Servers A and B only need to store a single packet at any given time and the rest of the packets would be "juggled" in the network.
Is it really possible to store data by "juggling" it through a network? Am I underestimating the overhead in receiving and sending packets?
EDIT: This is assuming 100% network reliability, which is probably a completely unrealistic assumption.
A network does have some sort of "storage" capacity, and it is usually measured by the "Bandwidth-delay product". (Think network as a pipe, then its storage-capacity, the amount of data(water) that the pipe can hold is the volume of that pipe, the area-length product.) If you use unreliable protocols such as UDP to do the "cyclic sending", the extra data that exceeds the capacity will simply lose. If you use TCP to do it, after filling up the "pipe", the sending will then fill up the internal sending buffer on the OS, and then block.
I am reading 《Internetworking with TCP/IP》 by Douglas Comer,and when talking about creating a tcp connection ,there is a problem:
Suppose an implementation of TCP use
initial sequence number 1 when it
creates a connection,Explain how a
system crash and restart can confuse a
remote system into believing that the
old connection remained open.
I can't figure out why,please help me,Thanks.
Consider why a connection may get duplicate sequence numbers normally.
Then consider how the receiving system would handle a packet with a "duplicate" sequence number (because the transmitting system started reusing sequence numbers in packets it is using try to re-establish a connection).
*Edit: *
OP says:
but when re-establish the connection,the transmitting system will send a segment with SYN code bit set(and the sequence number be set 1 of course),won't that(SYN code bit set) inform the receiving system it is a new connection trying to be established ?see wiki for Transmission_Control_Protocol,it says that "Only the first packet sent from each end should have this flag(SYN) set."
But packets get lost and delayed and arrive out of order. You can't simply say everything arriving after the packet with the SYN flag is new. Lets say some of the old packets are delayed and arrive after establishment of a new connection. How do you distinguish whether a packet with sequence number #10 is from the old connection or new one? The worse case scenario is that it's from the old connection and the receiving system accepts it as from the new connection. When the real new connection packet #10 arrives, it's ignored as an unnecessary retranmission. The stream is corrupted without any indication of it.
http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentSequenceNumberSynchroniz.htm
... The problem with starting off each connection with a sequence number of 1 is that it introduces the possibility of segments from different connections getting mixed up. Suppose we established a TCP connection and sent a segment containing bytes 1 through 30. However, there was a problem with the internetwork that caused this segment to be delayed, and eventually, the TCP connection itself to be terminated. We then started up a new connection and again used a starting sequence number of 1. As soon as this new connection was started, however, the old segment with bytes labeled 1 to 30 showed up. The other device would erroneously think those bytes were part of the new connection.
... This is but one of several similar problems that can occur. ...
The other issue with a predictable initial sequence number, such as starting at 1 every time, is that the predictability presents a vulnerability:
A malicious person could write code to analyze ISNs and then predict the ISN of a subsequent TCP connection based on the ISNs used in earlier ones. This represents a security risk, which has been exploited in the past (such as in the case of the famous Mitnick attack). To defeat this, implementations now use a random number in their ISN selection process.
Mitnick attack - http://www.cas.mcmaster.ca/wiki/index.php/The_Mitnick_attack
It's far worse than that though anyway - being predictable with sequence numbers makes spoofing and injecting an order of magnitude easier
After restart, if the first TCP connection is towards the same remote system, and since the sequence number will again be 1 - consider what that will cause.
Why is data not transferred during the 3rd part of TCP 3-way handshake?
e.g.
(A to B)SYN
(B to A)ACK+SYN
(A to B) ACK.... why cant data be transferred along with this ACK?
I've always believed it was to keep the session establishment phase separate from the data transfer phase so that no real data is transferred until both ends of the session have agreed on the sequence numbers and session options, especially since packets arriving may be from a totally different, previous, session that just happens to have the same endpoints.
However, on further investigation, I'm not entirely certain that transmitting data with the handshake packets is disallowed. The section on TCP connection establishment in my Internetworking with TCP/IP1 book contains the following snippet:
Because of the protocol design, it is possible to send data along with the initial sequence numbers in the handshake segments. In such cases, the TCP software must hold the data until the handshake completes. Once a connection has been established, the TCP software can release data being held and deliver it to a waiting application program quickly.
Since it's certainly possible to construct a TCP packet with SYN (or ACK) and data, this may well be allowed. I've never seen it happen in the wild but, then again, I've never seen a hairy-eared dwarf lemur in the wild either, though I'm assured they exist.
It may be that it's the sockets software that prevents data going out before the session is fully established but TCP appears to consider it valid. It appears you can send data with a SYN-ACK packet (phase 2 of the connection establishment) since you have the other end's sequence number and options. Likewise, sending data with the phase 3 ACK packet appears to be possible as well.
The reason the TCP software holds on to the data until the handshake is fully complete is probably due to the reason mentioned above - only once both ends have agreed on the sequence numbers can you be sure that the data is not from a previous session.
1 Internetworking with TCP/IP Volume 1 Principles, Protocols and Architecture, 3rd edition, Douglas E. Comer, ISBN 0-13-216987-8.