What does a suspended TCP process in linux exactly do and do not?
Regarding TCP connections using NetGui (and wireshark for analyzing):
I set a TCP connection between two PCs using the command nc -p 11111 etc... for the server, and the corresponding one for the client, so that they were indeed able to send and read (in pc2 (server)) messages.
After that, I pressed Ctrl Z in pc2 (server should be suspended) and sent some messages with pc1 (client). By using netstat -tna command I'm able to see the messages waiting in the buffer. Before bringing the server back to foreground I stop the tcpdump capture in the router between these two pcs and realize that these messages had been sent (as expected) but also ACKed by the server.
Now, if the server ACKs messages as they leave the buffer (i.e. as they are processed and moved up to another layer), were these messages really 'grabbed' from the buffer by the server? If so, what is the meaning of being suspended?
If, however, messages are ACKed before being processed, then wouldn't pc1 think these messages have been processed and so, the buffer is free and keep sending messages until the window gets zero value? If so, what is the meaning of the following formula?
rwnd = ReceiveBuffer - (LastByteReceived – LastByteReadByApplication)
Where am I wrong?
linux networking tcp wireshark
edited Jan 14 at 16:59
Ahmed Ashour
1,3251715
asked Jan 14 at 15:05
PabloPablo
102
add a comment |
Regarding TCP connections using NetGui (and wireshark for analyzing):
I set a TCP connection between two PCs using the command nc -p 11111 etc... for the server, and the corresponding one for the client, so that they were indeed able to send and read (in pc2 (server)) messages.
After that, I pressed Ctrl Z in pc2 (server should be suspended) and sent some messages with pc1 (client). By using netstat -tna command I'm able to see the messages waiting in the buffer. Before bringing the server back to foreground I stop the tcpdump capture in the router between these two pcs and realize that these messages had been sent (as expected) but also ACKed by the server.
Now, if the server ACKs messages as they leave the buffer (i.e. as they are processed and moved up to another layer), were these messages really 'grabbed' from the buffer by the server? If so, what is the meaning of being suspended?
If, however, messages are ACKed before being processed, then wouldn't pc1 think these messages have been processed and so, the buffer is free and keep sending messages until the window gets zero value? If so, what is the meaning of the following formula?
rwnd = ReceiveBuffer - (LastByteReceived – LastByteReadByApplication)
Where am I wrong?
linux networking tcp wireshark
edited Jan 14 at 16:59
Ahmed Ashour
1,3251715
asked Jan 14 at 15:05
PabloPablo
102
add a comment |
Regarding TCP connections using NetGui (and wireshark for analyzing):
I set a TCP connection between two PCs using the command nc -p 11111 etc... for the server, and the corresponding one for the client, so that they were indeed able to send and read (in pc2 (server)) messages.
After that, I pressed Ctrl Z in pc2 (server should be suspended) and sent some messages with pc1 (client). By using netstat -tna command I'm able to see the messages waiting in the buffer. Before bringing the server back to foreground I stop the tcpdump capture in the router between these two pcs and realize that these messages had been sent (as expected) but also ACKed by the server.
Now, if the server ACKs messages as they leave the buffer (i.e. as they are processed and moved up to another layer), were these messages really 'grabbed' from the buffer by the server? If so, what is the meaning of being suspended?
If, however, messages are ACKed before being processed, then wouldn't pc1 think these messages have been processed and so, the buffer is free and keep sending messages until the window gets zero value? If so, what is the meaning of the following formula?
rwnd = ReceiveBuffer - (LastByteReceived – LastByteReadByApplication)
Where am I wrong?
linux networking tcp wireshark
edited Jan 14 at 16:59
Ahmed Ashour
1,3251715
asked Jan 14 at 15:05
PabloPablo
102
Regarding TCP connections using NetGui (and wireshark for analyzing):
I set a TCP connection between two PCs using the command nc -p 11111 etc... for the server, and the corresponding one for the client, so that they were indeed able to send and read (in pc2 (server)) messages.
After that, I pressed Ctrl Z in pc2 (server should be suspended) and sent some messages with pc1 (client). By using netstat -tna command I'm able to see the messages waiting in the buffer. Before bringing the server back to foreground I stop the tcpdump capture in the router between these two pcs and realize that these messages had been sent (as expected) but also ACKed by the server.
Now, if the server ACKs messages as they leave the buffer (i.e. as they are processed and moved up to another layer), were these messages really 'grabbed' from the buffer by the server? If so, what is the meaning of being suspended?
If, however, messages are ACKed before being processed, then wouldn't pc1 think these messages have been processed and so, the buffer is free and keep sending messages until the window gets zero value? If so, what is the meaning of the following formula?
rwnd = ReceiveBuffer - (LastByteReceived – LastByteReadByApplication)
Where am I wrong?
linux networking tcp wireshark
linux networking tcp wireshark
edited Jan 14 at 16:59
Ahmed Ashour
1,3251715
asked Jan 14 at 15:05
PabloPablo
102
edited Jan 14 at 16:59
Ahmed Ashour
1,3251715
asked Jan 14 at 15:05
PabloPablo
102
edited Jan 14 at 16:59
Ahmed Ashour
1,3251715
edited Jan 14 at 16:59
Ahmed Ashour
1,3251715
edited Jan 14 at 16:59
Ahmed Ashour
1,3251715
1,3251715
asked Jan 14 at 15:05
PabloPablo
102
asked Jan 14 at 15:05
PabloPablo
102
asked Jan 14 at 15:05
PabloPablo
102
102
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
TCP segments are Acked by the TCP stack in the kernel at the time the kernel TCP stack receives them from the NIC driver. So yes, the TCP receive window represents a buffer in the kernel, and if the destination process never reads the incoming data that has been buffered in the kernel, the receive window will fill up and the sender will stop sending.
The sender will then start doing "zero-window probes"; that is, it will send empty TCP segments just to get the receiver TCP stack to send back Acks with receive window updates, to see if any room in the receive window has opened up so the sender can start sending again. Once the destination process finally reads some of the data the kernel has buffered for it, the sender's next zero-window probe will result in an Ack with a receive window update showing room in the receive window, so the sender will resume sending payload-bearing TCP segments.
answered Jan 14 at 18:22
SpiffSpiff
77.7k10118163
Thank you, Spiff for replying. So basically the server doesn´t read the incoming messages, since it is in a suspended state, but it does ACK those messages (even in suspended state?) and this would eventually lead to a window fill up. Would that be correct?
– Pablo
Jan 14 at 20:08
The server process (netcat/ncin your example) never Acks anything, even when it's running. TCP Acks are always the exclusive responsibility of the TCP/IP stack in the kernel. It is never the responsibility of processes likenc. So whenncis suspended, it can't call read() on the TCP socket it's listening on, so the data buffered for it in the kernel builds up until the kernel's receive window for that connection fills up completely.
– Spiff
Jan 14 at 21:01
Understood. Great job and muchas gracias, Spiff
– Pablo
Jan 14 at 22:16
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%2f1394151%2fwhat-does-a-suspended-tcp-process-in-linux-exactly-do-and-do-not%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
TCP segments are Acked by the TCP stack in the kernel at the time the kernel TCP stack receives them from the NIC driver. So yes, the TCP receive window represents a buffer in the kernel, and if the destination process never reads the incoming data that has been buffered in the kernel, the receive window will fill up and the sender will stop sending.
The sender will then start doing "zero-window probes"; that is, it will send empty TCP segments just to get the receiver TCP stack to send back Acks with receive window updates, to see if any room in the receive window has opened up so the sender can start sending again. Once the destination process finally reads some of the data the kernel has buffered for it, the sender's next zero-window probe will result in an Ack with a receive window update showing room in the receive window, so the sender will resume sending payload-bearing TCP segments.
answered Jan 14 at 18:22
SpiffSpiff
77.7k10118163
Thank you, Spiff for replying. So basically the server doesn´t read the incoming messages, since it is in a suspended state, but it does ACK those messages (even in suspended state?) and this would eventually lead to a window fill up. Would that be correct?
– Pablo
Jan 14 at 20:08
The server process (netcat/ncin your example) never Acks anything, even when it's running. TCP Acks are always the exclusive responsibility of the TCP/IP stack in the kernel. It is never the responsibility of processes likenc. So whenncis suspended, it can't call read() on the TCP socket it's listening on, so the data buffered for it in the kernel builds up until the kernel's receive window for that connection fills up completely.
– Spiff
Jan 14 at 21:01
Understood. Great job and muchas gracias, Spiff
– Pablo
Jan 14 at 22:16
add a comment |
TCP segments are Acked by the TCP stack in the kernel at the time the kernel TCP stack receives them from the NIC driver. So yes, the TCP receive window represents a buffer in the kernel, and if the destination process never reads the incoming data that has been buffered in the kernel, the receive window will fill up and the sender will stop sending.
The sender will then start doing "zero-window probes"; that is, it will send empty TCP segments just to get the receiver TCP stack to send back Acks with receive window updates, to see if any room in the receive window has opened up so the sender can start sending again. Once the destination process finally reads some of the data the kernel has buffered for it, the sender's next zero-window probe will result in an Ack with a receive window update showing room in the receive window, so the sender will resume sending payload-bearing TCP segments.
answered Jan 14 at 18:22
SpiffSpiff
77.7k10118163
Thank you, Spiff for replying. So basically the server doesn´t read the incoming messages, since it is in a suspended state, but it does ACK those messages (even in suspended state?) and this would eventually lead to a window fill up. Would that be correct?
– Pablo
Jan 14 at 20:08
The server process (netcat/ncin your example) never Acks anything, even when it's running. TCP Acks are always the exclusive responsibility of the TCP/IP stack in the kernel. It is never the responsibility of processes likenc. So whenncis suspended, it can't call read() on the TCP socket it's listening on, so the data buffered for it in the kernel builds up until the kernel's receive window for that connection fills up completely.
– Spiff
Jan 14 at 21:01
Understood. Great job and muchas gracias, Spiff
– Pablo
Jan 14 at 22:16
add a comment |
TCP segments are Acked by the TCP stack in the kernel at the time the kernel TCP stack receives them from the NIC driver. So yes, the TCP receive window represents a buffer in the kernel, and if the destination process never reads the incoming data that has been buffered in the kernel, the receive window will fill up and the sender will stop sending.
The sender will then start doing "zero-window probes"; that is, it will send empty TCP segments just to get the receiver TCP stack to send back Acks with receive window updates, to see if any room in the receive window has opened up so the sender can start sending again. Once the destination process finally reads some of the data the kernel has buffered for it, the sender's next zero-window probe will result in an Ack with a receive window update showing room in the receive window, so the sender will resume sending payload-bearing TCP segments.
answered Jan 14 at 18:22
SpiffSpiff
77.7k10118163
TCP segments are Acked by the TCP stack in the kernel at the time the kernel TCP stack receives them from the NIC driver. So yes, the TCP receive window represents a buffer in the kernel, and if the destination process never reads the incoming data that has been buffered in the kernel, the receive window will fill up and the sender will stop sending.
The sender will then start doing "zero-window probes"; that is, it will send empty TCP segments just to get the receiver TCP stack to send back Acks with receive window updates, to see if any room in the receive window has opened up so the sender can start sending again. Once the destination process finally reads some of the data the kernel has buffered for it, the sender's next zero-window probe will result in an Ack with a receive window update showing room in the receive window, so the sender will resume sending payload-bearing TCP segments.
answered Jan 14 at 18:22
SpiffSpiff
77.7k10118163
answered Jan 14 at 18:22
SpiffSpiff
77.7k10118163
answered Jan 14 at 18:22
SpiffSpiff
77.7k10118163
answered Jan 14 at 18:22
SpiffSpiff
77.7k10118163
77.7k10118163
Thank you, Spiff for replying. So basically the server doesn´t read the incoming messages, since it is in a suspended state, but it does ACK those messages (even in suspended state?) and this would eventually lead to a window fill up. Would that be correct?
– Pablo
Jan 14 at 20:08
The server process (netcat/ncin your example) never Acks anything, even when it's running. TCP Acks are always the exclusive responsibility of the TCP/IP stack in the kernel. It is never the responsibility of processes likenc. So whenncis suspended, it can't call read() on the TCP socket it's listening on, so the data buffered for it in the kernel builds up until the kernel's receive window for that connection fills up completely.
– Spiff
Jan 14 at 21:01
Understood. Great job and muchas gracias, Spiff
– Pablo
Jan 14 at 22:16
add a comment |
Thank you, Spiff for replying. So basically the server doesn´t read the incoming messages, since it is in a suspended state, but it does ACK those messages (even in suspended state?) and this would eventually lead to a window fill up. Would that be correct?
– Pablo
Jan 14 at 20:08
The server process (netcat/ncin your example) never Acks anything, even when it's running. TCP Acks are always the exclusive responsibility of the TCP/IP stack in the kernel. It is never the responsibility of processes likenc. So whenncis suspended, it can't call read() on the TCP socket it's listening on, so the data buffered for it in the kernel builds up until the kernel's receive window for that connection fills up completely.
– Spiff
Jan 14 at 21:01
Understood. Great job and muchas gracias, Spiff
– Pablo
Jan 14 at 22:16
Thank you, Spiff for replying. So basically the server doesn´t read the incoming messages, since it is in a suspended state, but it does ACK those messages (even in suspended state?) and this would eventually lead to a window fill up. Would that be correct?
– Pablo
Jan 14 at 20:08
Thank you, Spiff for replying. So basically the server doesn´t read the incoming messages, since it is in a suspended state, but it does ACK those messages (even in suspended state?) and this would eventually lead to a window fill up. Would that be correct?
– Pablo
Jan 14 at 20:08
The server process (netcat/
nc in your example) never Acks anything, even when it's running. TCP Acks are always the exclusive responsibility of the TCP/IP stack in the kernel. It is never the responsibility of processes like nc. So when nc is suspended, it can't call read() on the TCP socket it's listening on, so the data buffered for it in the kernel builds up until the kernel's receive window for that connection fills up completely.– Spiff
Jan 14 at 21:01
The server process (netcat/
nc in your example) never Acks anything, even when it's running. TCP Acks are always the exclusive responsibility of the TCP/IP stack in the kernel. It is never the responsibility of processes like nc. So when nc is suspended, it can't call read() on the TCP socket it's listening on, so the data buffered for it in the kernel builds up until the kernel's receive window for that connection fills up completely.– Spiff
Jan 14 at 21:01
Understood. Great job and muchas gracias, Spiff
– Pablo
Jan 14 at 22:16
Understood. Great job and muchas gracias, Spiff
– Pablo
Jan 14 at 22:16
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.
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%2f1394151%2fwhat-does-a-suspended-tcp-process-in-linux-exactly-do-and-do-not%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
