Connection remains flagged as ESTABLISHED even if host is unconnected
I am working on a Linux embedded distribution and I need to monitor incoming and outcoming connections (if they are still actives etc.) and I am experiencing issues because I noticed that, even if the remote host turn off the connection, I can see the connection as ESTABLISHED through netstat.
I have two different versions of this Linux embedded system: one which uses an old 2.6.34 kernel and it works fine, while the one which is failing uses a kernel 3.18.18.
Looking for more information I suspect I had to set/change TCP timeouts, so I configured them through syctl.conf but doesn't change anything.
The system which uses 2.6.34 kernel doesn't have TCP timeouts configured, so it makes me think that TCP are not the root of my problem.
Do you have an idea about what could be the reason of the fact that the connection remain as ESTABLISHED?
linux networking tcp timeout
edited Jan 5 '16 at 12:03
JohannesM
716717
asked Jan 5 '16 at 8:29
simo-zz
14116
|
show 6 more comments
I am working on a Linux embedded distribution and I need to monitor incoming and outcoming connections (if they are still actives etc.) and I am experiencing issues because I noticed that, even if the remote host turn off the connection, I can see the connection as ESTABLISHED through netstat.
I have two different versions of this Linux embedded system: one which uses an old 2.6.34 kernel and it works fine, while the one which is failing uses a kernel 3.18.18.
Looking for more information I suspect I had to set/change TCP timeouts, so I configured them through syctl.conf but doesn't change anything.
The system which uses 2.6.34 kernel doesn't have TCP timeouts configured, so it makes me think that TCP are not the root of my problem.
Do you have an idea about what could be the reason of the fact that the connection remain as ESTABLISHED?
linux networking tcp timeout
edited Jan 5 '16 at 12:03
JohannesM
716717
asked Jan 5 '16 at 8:29
simo-zz
14116
This is just the way TCP works. A connection can remain established for days or even weeks without a single packet being exchanged. If you don't send, there's no way to know what will happen if you do send. Your question is too vague to give you a helpful answer to though because you don't explain your outer problem, just ask for help with a proposed solution. Are you writing application code that actually implements the TCP endpoint? If so, what protocol does it use on top of TCP? Or are you trying to monitor some other application's connections? Or what?
– David Schwartz
Jan 5 '16 at 9:15
I am trying to monitor some other application's connections. If I was writing code I would have specified it. I have a remote host (Windows client) which connects to my Linux system (server) and once the client is connected it starts to retrieve data from server through TCP protocol. If the client disconnects, the connection on the server does not disappear. It remains as established. The same softwares are used on a old Linux system (as specified in the question) and it works all fine.
– simo-zz
Jan 5 '16 at 9:43
That's all normal. The disconnection should be detected as soon as the connected side tries to send data. Obviously, a disconnected device can't send any data, so there's no way to magically know that it's disconnected until it fails to respond to a query.
– David Schwartz
Jan 5 '16 at 9:45
1
The timeout only works if the connected side is trying to send data. Otherwise, there's nothing to time out. A TCP connection can remain established for days without a single packet being sent if neither side tries to send any data. In general, the only way to detect a disconnected device is to try to send data to it. If you don't ever send any data, you're simply not assured of detecting it. What application protocol (on top of TCP) are we talking about here?
– David Schwartz
Jan 5 '16 at 9:50
1
Well then the sending of data should cause the connection loss to be detected. The application on the other side needs to send data periodically too, or detect the absence of received data. It has to do something if it needs to detect connection loss.
– David Schwartz
Jan 5 '16 at 10:23
|
show 6 more comments
I am working on a Linux embedded distribution and I need to monitor incoming and outcoming connections (if they are still actives etc.) and I am experiencing issues because I noticed that, even if the remote host turn off the connection, I can see the connection as ESTABLISHED through netstat.
I have two different versions of this Linux embedded system: one which uses an old 2.6.34 kernel and it works fine, while the one which is failing uses a kernel 3.18.18.
Looking for more information I suspect I had to set/change TCP timeouts, so I configured them through syctl.conf but doesn't change anything.
The system which uses 2.6.34 kernel doesn't have TCP timeouts configured, so it makes me think that TCP are not the root of my problem.
Do you have an idea about what could be the reason of the fact that the connection remain as ESTABLISHED?
linux networking tcp timeout
edited Jan 5 '16 at 12:03
JohannesM
716717
asked Jan 5 '16 at 8:29
simo-zz
14116
I am working on a Linux embedded distribution and I need to monitor incoming and outcoming connections (if they are still actives etc.) and I am experiencing issues because I noticed that, even if the remote host turn off the connection, I can see the connection as ESTABLISHED through netstat.
I have two different versions of this Linux embedded system: one which uses an old 2.6.34 kernel and it works fine, while the one which is failing uses a kernel 3.18.18.
Looking for more information I suspect I had to set/change TCP timeouts, so I configured them through syctl.conf but doesn't change anything.
The system which uses 2.6.34 kernel doesn't have TCP timeouts configured, so it makes me think that TCP are not the root of my problem.
Do you have an idea about what could be the reason of the fact that the connection remain as ESTABLISHED?
linux networking tcp timeout
linux networking tcp timeout
edited Jan 5 '16 at 12:03
JohannesM
716717
asked Jan 5 '16 at 8:29
simo-zz
14116
edited Jan 5 '16 at 12:03
JohannesM
716717
asked Jan 5 '16 at 8:29
simo-zz
14116
edited Jan 5 '16 at 12:03
JohannesM
716717
edited Jan 5 '16 at 12:03
JohannesM
716717
edited Jan 5 '16 at 12:03
JohannesM
716717
716717
asked Jan 5 '16 at 8:29
simo-zz
14116
asked Jan 5 '16 at 8:29
simo-zz
14116
asked Jan 5 '16 at 8:29
simo-zz
14116
14116
This is just the way TCP works. A connection can remain established for days or even weeks without a single packet being exchanged. If you don't send, there's no way to know what will happen if you do send. Your question is too vague to give you a helpful answer to though because you don't explain your outer problem, just ask for help with a proposed solution. Are you writing application code that actually implements the TCP endpoint? If so, what protocol does it use on top of TCP? Or are you trying to monitor some other application's connections? Or what?
– David Schwartz
Jan 5 '16 at 9:15
I am trying to monitor some other application's connections. If I was writing code I would have specified it. I have a remote host (Windows client) which connects to my Linux system (server) and once the client is connected it starts to retrieve data from server through TCP protocol. If the client disconnects, the connection on the server does not disappear. It remains as established. The same softwares are used on a old Linux system (as specified in the question) and it works all fine.
– simo-zz
Jan 5 '16 at 9:43
That's all normal. The disconnection should be detected as soon as the connected side tries to send data. Obviously, a disconnected device can't send any data, so there's no way to magically know that it's disconnected until it fails to respond to a query.
– David Schwartz
Jan 5 '16 at 9:45
1
The timeout only works if the connected side is trying to send data. Otherwise, there's nothing to time out. A TCP connection can remain established for days without a single packet being sent if neither side tries to send any data. In general, the only way to detect a disconnected device is to try to send data to it. If you don't ever send any data, you're simply not assured of detecting it. What application protocol (on top of TCP) are we talking about here?
– David Schwartz
Jan 5 '16 at 9:50
1
Well then the sending of data should cause the connection loss to be detected. The application on the other side needs to send data periodically too, or detect the absence of received data. It has to do something if it needs to detect connection loss.
– David Schwartz
Jan 5 '16 at 10:23
|
show 6 more comments
This is just the way TCP works. A connection can remain established for days or even weeks without a single packet being exchanged. If you don't send, there's no way to know what will happen if you do send. Your question is too vague to give you a helpful answer to though because you don't explain your outer problem, just ask for help with a proposed solution. Are you writing application code that actually implements the TCP endpoint? If so, what protocol does it use on top of TCP? Or are you trying to monitor some other application's connections? Or what?
– David Schwartz
Jan 5 '16 at 9:15
I am trying to monitor some other application's connections. If I was writing code I would have specified it. I have a remote host (Windows client) which connects to my Linux system (server) and once the client is connected it starts to retrieve data from server through TCP protocol. If the client disconnects, the connection on the server does not disappear. It remains as established. The same softwares are used on a old Linux system (as specified in the question) and it works all fine.
– simo-zz
Jan 5 '16 at 9:43
That's all normal. The disconnection should be detected as soon as the connected side tries to send data. Obviously, a disconnected device can't send any data, so there's no way to magically know that it's disconnected until it fails to respond to a query.
– David Schwartz
Jan 5 '16 at 9:45
1
The timeout only works if the connected side is trying to send data. Otherwise, there's nothing to time out. A TCP connection can remain established for days without a single packet being sent if neither side tries to send any data. In general, the only way to detect a disconnected device is to try to send data to it. If you don't ever send any data, you're simply not assured of detecting it. What application protocol (on top of TCP) are we talking about here?
– David Schwartz
Jan 5 '16 at 9:50
1
Well then the sending of data should cause the connection loss to be detected. The application on the other side needs to send data periodically too, or detect the absence of received data. It has to do something if it needs to detect connection loss.
– David Schwartz
Jan 5 '16 at 10:23
This is just the way TCP works. A connection can remain established for days or even weeks without a single packet being exchanged. If you don't send, there's no way to know what will happen if you do send. Your question is too vague to give you a helpful answer to though because you don't explain your outer problem, just ask for help with a proposed solution. Are you writing application code that actually implements the TCP endpoint? If so, what protocol does it use on top of TCP? Or are you trying to monitor some other application's connections? Or what?
– David Schwartz
Jan 5 '16 at 9:15
This is just the way TCP works. A connection can remain established for days or even weeks without a single packet being exchanged. If you don't send, there's no way to know what will happen if you do send. Your question is too vague to give you a helpful answer to though because you don't explain your outer problem, just ask for help with a proposed solution. Are you writing application code that actually implements the TCP endpoint? If so, what protocol does it use on top of TCP? Or are you trying to monitor some other application's connections? Or what?
– David Schwartz
Jan 5 '16 at 9:15
I am trying to monitor some other application's connections. If I was writing code I would have specified it. I have a remote host (Windows client) which connects to my Linux system (server) and once the client is connected it starts to retrieve data from server through TCP protocol. If the client disconnects, the connection on the server does not disappear. It remains as established. The same softwares are used on a old Linux system (as specified in the question) and it works all fine.
– simo-zz
Jan 5 '16 at 9:43
I am trying to monitor some other application's connections. If I was writing code I would have specified it. I have a remote host (Windows client) which connects to my Linux system (server) and once the client is connected it starts to retrieve data from server through TCP protocol. If the client disconnects, the connection on the server does not disappear. It remains as established. The same softwares are used on a old Linux system (as specified in the question) and it works all fine.
– simo-zz
Jan 5 '16 at 9:43
That's all normal. The disconnection should be detected as soon as the connected side tries to send data. Obviously, a disconnected device can't send any data, so there's no way to magically know that it's disconnected until it fails to respond to a query.
– David Schwartz
Jan 5 '16 at 9:45
That's all normal. The disconnection should be detected as soon as the connected side tries to send data. Obviously, a disconnected device can't send any data, so there's no way to magically know that it's disconnected until it fails to respond to a query.
– David Schwartz
Jan 5 '16 at 9:45
1
1
The timeout only works if the connected side is trying to send data. Otherwise, there's nothing to time out. A TCP connection can remain established for days without a single packet being sent if neither side tries to send any data. In general, the only way to detect a disconnected device is to try to send data to it. If you don't ever send any data, you're simply not assured of detecting it. What application protocol (on top of TCP) are we talking about here?
– David Schwartz
Jan 5 '16 at 9:50
The timeout only works if the connected side is trying to send data. Otherwise, there's nothing to time out. A TCP connection can remain established for days without a single packet being sent if neither side tries to send any data. In general, the only way to detect a disconnected device is to try to send data to it. If you don't ever send any data, you're simply not assured of detecting it. What application protocol (on top of TCP) are we talking about here?
– David Schwartz
Jan 5 '16 at 9:50
1
1
Well then the sending of data should cause the connection loss to be detected. The application on the other side needs to send data periodically too, or detect the absence of received data. It has to do something if it needs to detect connection loss.
– David Schwartz
Jan 5 '16 at 10:23
Well then the sending of data should cause the connection loss to be detected. The application on the other side needs to send data periodically too, or detect the absence of received data. It has to do something if it needs to detect connection loss.
– David Schwartz
Jan 5 '16 at 10:23
|
show 6 more comments
1 Answer
1
active
oldest
votes
If a host disconnects from the other and you still see its connection as ESTABLISHED, it's probably related to the fact it's not honoring the TCP protocol and not closing the connection cleanly.
The netstat output is an interpreter of the current state of TCP connections. If a client wants to disconnect/close the socket that has previously been open and established, they should notify this to the remote system. This is done sending the FIN request to the other node (more info here), in this case, the server.
It they fail to do so, the client indeed disconnects, but the remote server keeps thinking that the client is still connected and thus keeping their state as ESTABLISHED, and that's where the tcp_keepalive_time parameter join the equation. As no further packets will be received, the kernel will wait the specified time to this parameter to time-out the connection and forcibly close it.
You can debug this issue using the tcpdump tool. You could simply listen to the connection from the client host on the server side and check if it fails to send the FIN request.
tcpdump host X.X.X.X and port Y
answered Jan 5 '16 at 9:06
nKn
4,48552231
OK. But I set the parametertcp_keepalive_timemany times, so there should be something else.
– simo-zz
Jan 5 '16 at 9:26
Did you runsysctl -pafter modifying the file?
– nKn
Jan 5 '16 at 9:29
Yes, I also executed this command. It's all as I have configured.
– simo-zz
Jan 5 '16 at 9:36
Then either the client has been not closed, or for some reason there still are packets being received on the server side. Note thatACKare not considered "idle-breaking" packets in this case. Note as well that any modifications made to the file do not affect any previouslyESTABLISHEDsockets, so it just affects newly established ones.
– nKn
Jan 5 '16 at 9:39
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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%2fsuperuser.com%2fquestions%2f1021988%2fconnection-remains-flagged-as-established-even-if-host-is-unconnected%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
If a host disconnects from the other and you still see its connection as ESTABLISHED, it's probably related to the fact it's not honoring the TCP protocol and not closing the connection cleanly.
The netstat output is an interpreter of the current state of TCP connections. If a client wants to disconnect/close the socket that has previously been open and established, they should notify this to the remote system. This is done sending the FIN request to the other node (more info here), in this case, the server.
It they fail to do so, the client indeed disconnects, but the remote server keeps thinking that the client is still connected and thus keeping their state as ESTABLISHED, and that's where the tcp_keepalive_time parameter join the equation. As no further packets will be received, the kernel will wait the specified time to this parameter to time-out the connection and forcibly close it.
You can debug this issue using the tcpdump tool. You could simply listen to the connection from the client host on the server side and check if it fails to send the FIN request.
tcpdump host X.X.X.X and port Y
answered Jan 5 '16 at 9:06
nKn
4,48552231
OK. But I set the parametertcp_keepalive_timemany times, so there should be something else.
– simo-zz
Jan 5 '16 at 9:26
Did you runsysctl -pafter modifying the file?
– nKn
Jan 5 '16 at 9:29
Yes, I also executed this command. It's all as I have configured.
– simo-zz
Jan 5 '16 at 9:36
Then either the client has been not closed, or for some reason there still are packets being received on the server side. Note thatACKare not considered "idle-breaking" packets in this case. Note as well that any modifications made to the file do not affect any previouslyESTABLISHEDsockets, so it just affects newly established ones.
– nKn
Jan 5 '16 at 9:39
add a comment |
If a host disconnects from the other and you still see its connection as ESTABLISHED, it's probably related to the fact it's not honoring the TCP protocol and not closing the connection cleanly.
The netstat output is an interpreter of the current state of TCP connections. If a client wants to disconnect/close the socket that has previously been open and established, they should notify this to the remote system. This is done sending the FIN request to the other node (more info here), in this case, the server.
It they fail to do so, the client indeed disconnects, but the remote server keeps thinking that the client is still connected and thus keeping their state as ESTABLISHED, and that's where the tcp_keepalive_time parameter join the equation. As no further packets will be received, the kernel will wait the specified time to this parameter to time-out the connection and forcibly close it.
You can debug this issue using the tcpdump tool. You could simply listen to the connection from the client host on the server side and check if it fails to send the FIN request.
tcpdump host X.X.X.X and port Y
answered Jan 5 '16 at 9:06
nKn
4,48552231
OK. But I set the parametertcp_keepalive_timemany times, so there should be something else.
– simo-zz
Jan 5 '16 at 9:26
Did you runsysctl -pafter modifying the file?
– nKn
Jan 5 '16 at 9:29
Yes, I also executed this command. It's all as I have configured.
– simo-zz
Jan 5 '16 at 9:36
Then either the client has been not closed, or for some reason there still are packets being received on the server side. Note thatACKare not considered "idle-breaking" packets in this case. Note as well that any modifications made to the file do not affect any previouslyESTABLISHEDsockets, so it just affects newly established ones.
– nKn
Jan 5 '16 at 9:39
add a comment |
If a host disconnects from the other and you still see its connection as ESTABLISHED, it's probably related to the fact it's not honoring the TCP protocol and not closing the connection cleanly.
The netstat output is an interpreter of the current state of TCP connections. If a client wants to disconnect/close the socket that has previously been open and established, they should notify this to the remote system. This is done sending the FIN request to the other node (more info here), in this case, the server.
It they fail to do so, the client indeed disconnects, but the remote server keeps thinking that the client is still connected and thus keeping their state as ESTABLISHED, and that's where the tcp_keepalive_time parameter join the equation. As no further packets will be received, the kernel will wait the specified time to this parameter to time-out the connection and forcibly close it.
You can debug this issue using the tcpdump tool. You could simply listen to the connection from the client host on the server side and check if it fails to send the FIN request.
tcpdump host X.X.X.X and port Y
answered Jan 5 '16 at 9:06
nKn
4,48552231
If a host disconnects from the other and you still see its connection as ESTABLISHED, it's probably related to the fact it's not honoring the TCP protocol and not closing the connection cleanly.
The netstat output is an interpreter of the current state of TCP connections. If a client wants to disconnect/close the socket that has previously been open and established, they should notify this to the remote system. This is done sending the FIN request to the other node (more info here), in this case, the server.
It they fail to do so, the client indeed disconnects, but the remote server keeps thinking that the client is still connected and thus keeping their state as ESTABLISHED, and that's where the tcp_keepalive_time parameter join the equation. As no further packets will be received, the kernel will wait the specified time to this parameter to time-out the connection and forcibly close it.
You can debug this issue using the tcpdump tool. You could simply listen to the connection from the client host on the server side and check if it fails to send the FIN request.
tcpdump host X.X.X.X and port Y
answered Jan 5 '16 at 9:06
nKn
4,48552231
answered Jan 5 '16 at 9:06
nKn
4,48552231
answered Jan 5 '16 at 9:06
nKn
4,48552231
answered Jan 5 '16 at 9:06
nKn
4,48552231
4,48552231
OK. But I set the parametertcp_keepalive_timemany times, so there should be something else.
– simo-zz
Jan 5 '16 at 9:26
Did you runsysctl -pafter modifying the file?
– nKn
Jan 5 '16 at 9:29
Yes, I also executed this command. It's all as I have configured.
– simo-zz
Jan 5 '16 at 9:36
Then either the client has been not closed, or for some reason there still are packets being received on the server side. Note thatACKare not considered "idle-breaking" packets in this case. Note as well that any modifications made to the file do not affect any previouslyESTABLISHEDsockets, so it just affects newly established ones.
– nKn
Jan 5 '16 at 9:39
add a comment |
OK. But I set the parametertcp_keepalive_timemany times, so there should be something else.
– simo-zz
Jan 5 '16 at 9:26
Did you runsysctl -pafter modifying the file?
– nKn
Jan 5 '16 at 9:29
Yes, I also executed this command. It's all as I have configured.
– simo-zz
Jan 5 '16 at 9:36
Then either the client has been not closed, or for some reason there still are packets being received on the server side. Note thatACKare not considered "idle-breaking" packets in this case. Note as well that any modifications made to the file do not affect any previouslyESTABLISHEDsockets, so it just affects newly established ones.
– nKn
Jan 5 '16 at 9:39
OK. But I set the parameter
tcp_keepalive_time many times, so there should be something else.– simo-zz
Jan 5 '16 at 9:26
OK. But I set the parameter
tcp_keepalive_time many times, so there should be something else.– simo-zz
Jan 5 '16 at 9:26
Did you run
sysctl -p after modifying the file?– nKn
Jan 5 '16 at 9:29
Did you run
sysctl -p after modifying the file?– nKn
Jan 5 '16 at 9:29
Yes, I also executed this command. It's all as I have configured.
– simo-zz
Jan 5 '16 at 9:36
Yes, I also executed this command. It's all as I have configured.
– simo-zz
Jan 5 '16 at 9:36
Then either the client has been not closed, or for some reason there still are packets being received on the server side. Note that
ACK are not considered "idle-breaking" packets in this case. Note as well that any modifications made to the file do not affect any previously ESTABLISHED sockets, so it just affects newly established ones.– nKn
Jan 5 '16 at 9:39
Then either the client has been not closed, or for some reason there still are packets being received on the server side. Note that
ACK are not considered "idle-breaking" packets in this case. Note as well that any modifications made to the file do not affect any previously ESTABLISHED sockets, so it just affects newly established ones.– nKn
Jan 5 '16 at 9:39
add a comment |
Thanks for contributing an answer to Super User!
- 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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2fsuperuser.com%2fquestions%2f1021988%2fconnection-remains-flagged-as-established-even-if-host-is-unconnected%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
This is just the way TCP works. A connection can remain established for days or even weeks without a single packet being exchanged. If you don't send, there's no way to know what will happen if you do send. Your question is too vague to give you a helpful answer to though because you don't explain your outer problem, just ask for help with a proposed solution. Are you writing application code that actually implements the TCP endpoint? If so, what protocol does it use on top of TCP? Or are you trying to monitor some other application's connections? Or what?
– David Schwartz
Jan 5 '16 at 9:15
I am trying to monitor some other application's connections. If I was writing code I would have specified it. I have a remote host (Windows client) which connects to my Linux system (server) and once the client is connected it starts to retrieve data from server through TCP protocol. If the client disconnects, the connection on the server does not disappear. It remains as established. The same softwares are used on a old Linux system (as specified in the question) and it works all fine.
– simo-zz
Jan 5 '16 at 9:43
That's all normal. The disconnection should be detected as soon as the connected side tries to send data. Obviously, a disconnected device can't send any data, so there's no way to magically know that it's disconnected until it fails to respond to a query.
– David Schwartz
Jan 5 '16 at 9:45
1
The timeout only works if the connected side is trying to send data. Otherwise, there's nothing to time out. A TCP connection can remain established for days without a single packet being sent if neither side tries to send any data. In general, the only way to detect a disconnected device is to try to send data to it. If you don't ever send any data, you're simply not assured of detecting it. What application protocol (on top of TCP) are we talking about here?
– David Schwartz
Jan 5 '16 at 9:50
1
Well then the sending of data should cause the connection loss to be detected. The application on the other side needs to send data periodically too, or detect the absence of received data. It has to do something if it needs to detect connection loss.
– David Schwartz
Jan 5 '16 at 10:23