If an old FIN is delivered, will TCP terminate the new connection?After TCP is established which BGP peer will send open message first?Continue to use the same connection after receiving [FIN, ACK]what is the difference between open TCP scan and half-open (stealth) TCP scan?Is application determined before or after TCP handshake?TCP - ack and retransmissions - Is this scenario possible?How would a firewall kill a TCP connection without RST or FIN?Does TCP open a new connection for every packet that is sent?TCP's three-way handshake and Denial of Service attackIs the first segment which is sent by the client in the 3 way handshake counted in the tcp congestion control?acknowledgment by TCP does not guarantee that the data has been delivered
no sense/need/point
What do you call a painting on a wall?
As black, how should one respond to 4. Qe2 by white in the Russian Game, Damiano Variation?
Why does blending blueberries, milk, banana and vanilla extract cause the mixture to have a yogurty consistency?
Has the Hulk always been able to talk?
Who filmed the Apollo 11 trans-lunar injection?
Simple Derivative Proof?
Is space itself expanding or is it just momentum from the Big Bang carrying things apart?
Clarification of algebra in moment generating functions
How to remap repeating commands i.e. <number><command>?
If an old FIN is delivered, will TCP terminate the new connection?
In linear regression why does regularisation penalise the parameter values as well?
Hostile Divisor Numbers
Sheared off exhasut pipe: How to fix without a welder?
It isn’t that you must stop now
Can my 2 children, aged 10 and 12, who are US citizens, travel to the USA on expired American passports?
How do I allocate more memory to an app on Sheepshaver running Mac OS 9?
Where are the "shires" in the UK?
Should I simplify my writing in a foreign country?
Dirichlet series with a single zero
Constitutional limitation of criminalizing behavior in US law?
Endgame puzzle: How to avoid stalemate and win?
What is a precise issue with allowing getters?
Why are oscilloscope input impedances so low?
If an old FIN is delivered, will TCP terminate the new connection?
After TCP is established which BGP peer will send open message first?Continue to use the same connection after receiving [FIN, ACK]what is the difference between open TCP scan and half-open (stealth) TCP scan?Is application determined before or after TCP handshake?TCP - ack and retransmissions - Is this scenario possible?How would a firewall kill a TCP connection without RST or FIN?Does TCP open a new connection for every packet that is sent?TCP's three-way handshake and Denial of Service attackIs the first segment which is sent by the client in the 3 way handshake counted in the tcp congestion control?acknowledgment by TCP does not guarantee that the data has been delivered
Two programs use a TCP connection (3-way handshake) to open, communicate, terminate the connection and open a new connection. If a FIN message sent to shut down the first connection is duplicated and delayed until the second connection has been established, then delivered, will the new connection be terminated?
tcp protocol-theory transport-protocol layer4
New contributor
add a comment |
Two programs use a TCP connection (3-way handshake) to open, communicate, terminate the connection and open a new connection. If a FIN message sent to shut down the first connection is duplicated and delayed until the second connection has been established, then delivered, will the new connection be terminated?
tcp protocol-theory transport-protocol layer4
New contributor
add a comment |
Two programs use a TCP connection (3-way handshake) to open, communicate, terminate the connection and open a new connection. If a FIN message sent to shut down the first connection is duplicated and delayed until the second connection has been established, then delivered, will the new connection be terminated?
tcp protocol-theory transport-protocol layer4
New contributor
Two programs use a TCP connection (3-way handshake) to open, communicate, terminate the connection and open a new connection. If a FIN message sent to shut down the first connection is duplicated and delayed until the second connection has been established, then delivered, will the new connection be terminated?
tcp protocol-theory transport-protocol layer4
tcp protocol-theory transport-protocol layer4
New contributor
New contributor
edited 4 hours ago
Ron Maupin♦
69.4k1370127
69.4k1370127
New contributor
asked 5 hours ago
rpersilyrpersily
82
82
New contributor
New contributor
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
No for at least two reasons:
- source and destination ports
- sequence number
Even though the pair source/destination ports is same as the first connection, the sequence number is unlikely to be same because the initial sequence number of a connection is supposed to be random.
The RST flag isn't seq nb dependent. Assuming the pair src/dst ports is same, a previous RST flag would terminate the session.
Thus, there is a very low probability that a duplicated FIN packet of another old already terminated session would terminate the new one.
You cannot even create a new session with the same socket pair until the full FIN handshake has finished, so there will not be a FIN from a previous connection.
– Ron Maupin♦
3 hours ago
In theory, I agree, when everything goes well. In practice, bugs are present especially with custom stacks that don't fully respect the specs.
– Alexis_FR_JP
3 hours ago
The actual host OS implementations are off-topic here. We can discuss protocol theory, but what a specific TCP implementation does in off-topic here, but may be asked on Server Fault or one of the OS-specific SE sites.
– Ron Maupin♦
3 hours ago
add a comment |
A FIN for one connection has nothing to do with a second connection. Remember that a connection is identified by two sockets (source and destination). Either you would have two separate connections where one of the sockets in the pair identifying the connection is different, in which case, the two sockets are completely separate, or you would be trying to establish an existing connection, which should result in a RST.
Basically, your situation could not occur because the two connections are entirely separate, or the second connection could not be established until the first connection is completely closed.
RFC 793, Transmission Control Protocol is the definition of TCP, and it explains how it works:
Multiplexing:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network and
host addresses from the internet communication layer, this forms a
socket. A pair of sockets uniquely identifies each connection. That
is, a socket may be simultaneously used in multiple connections.
The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed through
the known addresses. Establishing and learning the port addresses of
other processes may involve more dynamic mechanisms.
Connections:
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for each
data stream. The combination of this information, including sockets,
sequence numbers, and window sizes, is called a connection. Each
connection is uniquely specified by a pair of sockets identifying its
two sides.
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid erroneous
initialization of connections.
-and-
Reset Generation
As a general rule, reset (RST) must be sent whenever a segment arrives
which apparently is not intended for the current connection. A reset
must not be sent if it is not clear that this is the case.
There are three groups of states:
If the connection does not exist (CLOSED) then a reset is sent in
response to any incoming segment except another reset. In
particular, SYNs addressed to a non-existent connection are rejected
by this means.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the CLOSED state.
If the connection is in any non-synchronized state (LISTEN,
SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
something not yet sent (the segment carries an unacceptable ACK), or
if an incoming segment has a security level or compartment which
does not exactly match the level and compartment requested for the
connection, a reset is sent.
If our SYN has not been acknowledged and the precedence level of the
incoming segment is higher than the precedence level requested then
either raise the local precedence level (if allowed by the user and
the system) or send a reset; or if the precedence level of the
incoming segment is lower than the precedence level requested then
continue as if the precedence matched exactly (if the remote TCP
cannot raise the precedence level to match ours this will be
detected in the next segment it sends, and the connection will be
terminated then). If our SYN has been acknowledged (perhaps in this
incoming segment) the precedence level of the incoming segment must
match the local precedence level exactly, if it does not a reset
must be sent.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the same state.
If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection,a reset is sent and
connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "496"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
rpersily is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f58907%2fif-an-old-fin-is-delivered-will-tcp-terminate-the-new-connection%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
No for at least two reasons:
- source and destination ports
- sequence number
Even though the pair source/destination ports is same as the first connection, the sequence number is unlikely to be same because the initial sequence number of a connection is supposed to be random.
The RST flag isn't seq nb dependent. Assuming the pair src/dst ports is same, a previous RST flag would terminate the session.
Thus, there is a very low probability that a duplicated FIN packet of another old already terminated session would terminate the new one.
You cannot even create a new session with the same socket pair until the full FIN handshake has finished, so there will not be a FIN from a previous connection.
– Ron Maupin♦
3 hours ago
In theory, I agree, when everything goes well. In practice, bugs are present especially with custom stacks that don't fully respect the specs.
– Alexis_FR_JP
3 hours ago
The actual host OS implementations are off-topic here. We can discuss protocol theory, but what a specific TCP implementation does in off-topic here, but may be asked on Server Fault or one of the OS-specific SE sites.
– Ron Maupin♦
3 hours ago
add a comment |
No for at least two reasons:
- source and destination ports
- sequence number
Even though the pair source/destination ports is same as the first connection, the sequence number is unlikely to be same because the initial sequence number of a connection is supposed to be random.
The RST flag isn't seq nb dependent. Assuming the pair src/dst ports is same, a previous RST flag would terminate the session.
Thus, there is a very low probability that a duplicated FIN packet of another old already terminated session would terminate the new one.
You cannot even create a new session with the same socket pair until the full FIN handshake has finished, so there will not be a FIN from a previous connection.
– Ron Maupin♦
3 hours ago
In theory, I agree, when everything goes well. In practice, bugs are present especially with custom stacks that don't fully respect the specs.
– Alexis_FR_JP
3 hours ago
The actual host OS implementations are off-topic here. We can discuss protocol theory, but what a specific TCP implementation does in off-topic here, but may be asked on Server Fault or one of the OS-specific SE sites.
– Ron Maupin♦
3 hours ago
add a comment |
No for at least two reasons:
- source and destination ports
- sequence number
Even though the pair source/destination ports is same as the first connection, the sequence number is unlikely to be same because the initial sequence number of a connection is supposed to be random.
The RST flag isn't seq nb dependent. Assuming the pair src/dst ports is same, a previous RST flag would terminate the session.
Thus, there is a very low probability that a duplicated FIN packet of another old already terminated session would terminate the new one.
No for at least two reasons:
- source and destination ports
- sequence number
Even though the pair source/destination ports is same as the first connection, the sequence number is unlikely to be same because the initial sequence number of a connection is supposed to be random.
The RST flag isn't seq nb dependent. Assuming the pair src/dst ports is same, a previous RST flag would terminate the session.
Thus, there is a very low probability that a duplicated FIN packet of another old already terminated session would terminate the new one.
edited 42 mins ago
answered 4 hours ago
Alexis_FR_JPAlexis_FR_JP
1607
1607
You cannot even create a new session with the same socket pair until the full FIN handshake has finished, so there will not be a FIN from a previous connection.
– Ron Maupin♦
3 hours ago
In theory, I agree, when everything goes well. In practice, bugs are present especially with custom stacks that don't fully respect the specs.
– Alexis_FR_JP
3 hours ago
The actual host OS implementations are off-topic here. We can discuss protocol theory, but what a specific TCP implementation does in off-topic here, but may be asked on Server Fault or one of the OS-specific SE sites.
– Ron Maupin♦
3 hours ago
add a comment |
You cannot even create a new session with the same socket pair until the full FIN handshake has finished, so there will not be a FIN from a previous connection.
– Ron Maupin♦
3 hours ago
In theory, I agree, when everything goes well. In practice, bugs are present especially with custom stacks that don't fully respect the specs.
– Alexis_FR_JP
3 hours ago
The actual host OS implementations are off-topic here. We can discuss protocol theory, but what a specific TCP implementation does in off-topic here, but may be asked on Server Fault or one of the OS-specific SE sites.
– Ron Maupin♦
3 hours ago
You cannot even create a new session with the same socket pair until the full FIN handshake has finished, so there will not be a FIN from a previous connection.
– Ron Maupin♦
3 hours ago
You cannot even create a new session with the same socket pair until the full FIN handshake has finished, so there will not be a FIN from a previous connection.
– Ron Maupin♦
3 hours ago
In theory, I agree, when everything goes well. In practice, bugs are present especially with custom stacks that don't fully respect the specs.
– Alexis_FR_JP
3 hours ago
In theory, I agree, when everything goes well. In practice, bugs are present especially with custom stacks that don't fully respect the specs.
– Alexis_FR_JP
3 hours ago
The actual host OS implementations are off-topic here. We can discuss protocol theory, but what a specific TCP implementation does in off-topic here, but may be asked on Server Fault or one of the OS-specific SE sites.
– Ron Maupin♦
3 hours ago
The actual host OS implementations are off-topic here. We can discuss protocol theory, but what a specific TCP implementation does in off-topic here, but may be asked on Server Fault or one of the OS-specific SE sites.
– Ron Maupin♦
3 hours ago
add a comment |
A FIN for one connection has nothing to do with a second connection. Remember that a connection is identified by two sockets (source and destination). Either you would have two separate connections where one of the sockets in the pair identifying the connection is different, in which case, the two sockets are completely separate, or you would be trying to establish an existing connection, which should result in a RST.
Basically, your situation could not occur because the two connections are entirely separate, or the second connection could not be established until the first connection is completely closed.
RFC 793, Transmission Control Protocol is the definition of TCP, and it explains how it works:
Multiplexing:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network and
host addresses from the internet communication layer, this forms a
socket. A pair of sockets uniquely identifies each connection. That
is, a socket may be simultaneously used in multiple connections.
The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed through
the known addresses. Establishing and learning the port addresses of
other processes may involve more dynamic mechanisms.
Connections:
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for each
data stream. The combination of this information, including sockets,
sequence numbers, and window sizes, is called a connection. Each
connection is uniquely specified by a pair of sockets identifying its
two sides.
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid erroneous
initialization of connections.
-and-
Reset Generation
As a general rule, reset (RST) must be sent whenever a segment arrives
which apparently is not intended for the current connection. A reset
must not be sent if it is not clear that this is the case.
There are three groups of states:
If the connection does not exist (CLOSED) then a reset is sent in
response to any incoming segment except another reset. In
particular, SYNs addressed to a non-existent connection are rejected
by this means.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the CLOSED state.
If the connection is in any non-synchronized state (LISTEN,
SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
something not yet sent (the segment carries an unacceptable ACK), or
if an incoming segment has a security level or compartment which
does not exactly match the level and compartment requested for the
connection, a reset is sent.
If our SYN has not been acknowledged and the precedence level of the
incoming segment is higher than the precedence level requested then
either raise the local precedence level (if allowed by the user and
the system) or send a reset; or if the precedence level of the
incoming segment is lower than the precedence level requested then
continue as if the precedence matched exactly (if the remote TCP
cannot raise the precedence level to match ours this will be
detected in the next segment it sends, and the connection will be
terminated then). If our SYN has been acknowledged (perhaps in this
incoming segment) the precedence level of the incoming segment must
match the local precedence level exactly, if it does not a reset
must be sent.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the same state.
If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection,a reset is sent and
connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
add a comment |
A FIN for one connection has nothing to do with a second connection. Remember that a connection is identified by two sockets (source and destination). Either you would have two separate connections where one of the sockets in the pair identifying the connection is different, in which case, the two sockets are completely separate, or you would be trying to establish an existing connection, which should result in a RST.
Basically, your situation could not occur because the two connections are entirely separate, or the second connection could not be established until the first connection is completely closed.
RFC 793, Transmission Control Protocol is the definition of TCP, and it explains how it works:
Multiplexing:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network and
host addresses from the internet communication layer, this forms a
socket. A pair of sockets uniquely identifies each connection. That
is, a socket may be simultaneously used in multiple connections.
The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed through
the known addresses. Establishing and learning the port addresses of
other processes may involve more dynamic mechanisms.
Connections:
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for each
data stream. The combination of this information, including sockets,
sequence numbers, and window sizes, is called a connection. Each
connection is uniquely specified by a pair of sockets identifying its
two sides.
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid erroneous
initialization of connections.
-and-
Reset Generation
As a general rule, reset (RST) must be sent whenever a segment arrives
which apparently is not intended for the current connection. A reset
must not be sent if it is not clear that this is the case.
There are three groups of states:
If the connection does not exist (CLOSED) then a reset is sent in
response to any incoming segment except another reset. In
particular, SYNs addressed to a non-existent connection are rejected
by this means.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the CLOSED state.
If the connection is in any non-synchronized state (LISTEN,
SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
something not yet sent (the segment carries an unacceptable ACK), or
if an incoming segment has a security level or compartment which
does not exactly match the level and compartment requested for the
connection, a reset is sent.
If our SYN has not been acknowledged and the precedence level of the
incoming segment is higher than the precedence level requested then
either raise the local precedence level (if allowed by the user and
the system) or send a reset; or if the precedence level of the
incoming segment is lower than the precedence level requested then
continue as if the precedence matched exactly (if the remote TCP
cannot raise the precedence level to match ours this will be
detected in the next segment it sends, and the connection will be
terminated then). If our SYN has been acknowledged (perhaps in this
incoming segment) the precedence level of the incoming segment must
match the local precedence level exactly, if it does not a reset
must be sent.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the same state.
If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection,a reset is sent and
connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
add a comment |
A FIN for one connection has nothing to do with a second connection. Remember that a connection is identified by two sockets (source and destination). Either you would have two separate connections where one of the sockets in the pair identifying the connection is different, in which case, the two sockets are completely separate, or you would be trying to establish an existing connection, which should result in a RST.
Basically, your situation could not occur because the two connections are entirely separate, or the second connection could not be established until the first connection is completely closed.
RFC 793, Transmission Control Protocol is the definition of TCP, and it explains how it works:
Multiplexing:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network and
host addresses from the internet communication layer, this forms a
socket. A pair of sockets uniquely identifies each connection. That
is, a socket may be simultaneously used in multiple connections.
The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed through
the known addresses. Establishing and learning the port addresses of
other processes may involve more dynamic mechanisms.
Connections:
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for each
data stream. The combination of this information, including sockets,
sequence numbers, and window sizes, is called a connection. Each
connection is uniquely specified by a pair of sockets identifying its
two sides.
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid erroneous
initialization of connections.
-and-
Reset Generation
As a general rule, reset (RST) must be sent whenever a segment arrives
which apparently is not intended for the current connection. A reset
must not be sent if it is not clear that this is the case.
There are three groups of states:
If the connection does not exist (CLOSED) then a reset is sent in
response to any incoming segment except another reset. In
particular, SYNs addressed to a non-existent connection are rejected
by this means.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the CLOSED state.
If the connection is in any non-synchronized state (LISTEN,
SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
something not yet sent (the segment carries an unacceptable ACK), or
if an incoming segment has a security level or compartment which
does not exactly match the level and compartment requested for the
connection, a reset is sent.
If our SYN has not been acknowledged and the precedence level of the
incoming segment is higher than the precedence level requested then
either raise the local precedence level (if allowed by the user and
the system) or send a reset; or if the precedence level of the
incoming segment is lower than the precedence level requested then
continue as if the precedence matched exactly (if the remote TCP
cannot raise the precedence level to match ours this will be
detected in the next segment it sends, and the connection will be
terminated then). If our SYN has been acknowledged (perhaps in this
incoming segment) the precedence level of the incoming segment must
match the local precedence level exactly, if it does not a reset
must be sent.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the same state.
If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection,a reset is sent and
connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
A FIN for one connection has nothing to do with a second connection. Remember that a connection is identified by two sockets (source and destination). Either you would have two separate connections where one of the sockets in the pair identifying the connection is different, in which case, the two sockets are completely separate, or you would be trying to establish an existing connection, which should result in a RST.
Basically, your situation could not occur because the two connections are entirely separate, or the second connection could not be established until the first connection is completely closed.
RFC 793, Transmission Control Protocol is the definition of TCP, and it explains how it works:
Multiplexing:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network and
host addresses from the internet communication layer, this forms a
socket. A pair of sockets uniquely identifies each connection. That
is, a socket may be simultaneously used in multiple connections.
The binding of ports to processes is handled independently by each
Host. However, it proves useful to attach frequently used processes
(e.g., a "logger" or timesharing service) to fixed sockets which are
made known to the public. These services can then be accessed through
the known addresses. Establishing and learning the port addresses of
other processes may involve more dynamic mechanisms.
Connections:
The reliability and flow control mechanisms described above require
that TCPs initialize and maintain certain status information for each
data stream. The combination of this information, including sockets,
sequence numbers, and window sizes, is called a connection. Each
connection is uniquely specified by a pair of sockets identifying its
two sides.
When two processes wish to communicate, their TCP's must first
establish a connection (initialize the status information on each
side). When their communication is complete, the connection is
terminated or closed to free the resources for other uses.
Since connections must be established between unreliable hosts and
over the unreliable internet communication system, a handshake
mechanism with clock-based sequence numbers is used to avoid erroneous
initialization of connections.
-and-
Reset Generation
As a general rule, reset (RST) must be sent whenever a segment arrives
which apparently is not intended for the current connection. A reset
must not be sent if it is not clear that this is the case.
There are three groups of states:
If the connection does not exist (CLOSED) then a reset is sent in
response to any incoming segment except another reset. In
particular, SYNs addressed to a non-existent connection are rejected
by this means.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the CLOSED state.
If the connection is in any non-synchronized state (LISTEN,
SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges
something not yet sent (the segment carries an unacceptable ACK), or
if an incoming segment has a security level or compartment which
does not exactly match the level and compartment requested for the
connection, a reset is sent.
If our SYN has not been acknowledged and the precedence level of the
incoming segment is higher than the precedence level requested then
either raise the local precedence level (if allowed by the user and
the system) or send a reset; or if the precedence level of the
incoming segment is lower than the precedence level requested then
continue as if the precedence matched exactly (if the remote TCP
cannot raise the precedence level to match ours this will be
detected in the next segment it sends, and the connection will be
terminated then). If our SYN has been acknowledged (perhaps in this
incoming segment) the precedence level of the incoming segment must
match the local precedence level exactly, if it does not a reset
must be sent.
If the incoming segment has an ACK field, the reset takes its
sequence number from the ACK field of the segment, otherwise the
reset has sequence number zero and the ACK field is set to the sum
of the sequence number and segment length of the incoming segment.
The connection remains in the same state.
If the connection is in a synchronized state (ESTABLISHED,
FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
any unacceptable segment (out of window sequence number or
unacceptible acknowledgment number) must elicit only an empty
acknowledgment segment containing the current send-sequence number
and an acknowledgment indicating the next sequence number expected
to be received, and the connection remains in the same state.
If an incoming segment has a security level, or compartment, or
precedence which does not exactly match the level, and compartment,
and precedence requested for the connection,a reset is sent and
connection goes to the CLOSED state. The reset takes its sequence
number from the ACK field of the incoming segment.
edited 4 hours ago
answered 5 hours ago
Ron Maupin♦Ron Maupin
69.4k1370127
69.4k1370127
add a comment |
add a comment |
rpersily is a new contributor. Be nice, and check out our Code of Conduct.
rpersily is a new contributor. Be nice, and check out our Code of Conduct.
rpersily is a new contributor. Be nice, and check out our Code of Conduct.
rpersily is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f58907%2fif-an-old-fin-is-delivered-will-tcp-terminate-the-new-connection%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown