Lowest TCP receive window size Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Data science time! April 2019 and salary with experience The Ask Question Wizard is Live!How to enable TCP_QUICKACK optionHow can I connect to Android with ADB over TCP?Who is listening on a given TCP port on Mac OS X?What is the maximum window size in segments of a TCP connection?Increasing TCP Window SizeBenefit of small TCP receive window?tcp receive window updateTCP receive window and congestion windowTCP receiving window size higher than net.core.rmem_maxHow is the window scale set/calculated in the TCP/IP implementation of the Linux kernel?Window Size when sender is faster than the receiver

As a dual citizen, my US passport will expire one day after traveling to the US. Will this work?

Besides transaction validation, are there any other uses of the Script language in Bitcoin

How to resize main filesystem

Does the main washing effect of soap come from foam?

Random body shuffle every night—can we still function?

Keep at all times, the minus sign above aligned with minus sign below

malloc in main() or malloc in another function: allocating memory for a struct and its members

My mentor says to set image to Fine instead of RAW — how is this different from JPG?

How does the body cool itself in a stillsuit?

Do i imagine the linear (straight line) homotopy in a correct way?

New Order #6: Easter Egg

Table formatting with tabularx?

Why do C and C++ allow the expression (int) + 4*5;

How to achieve cat-like agility?

.bashrc alias for a command with fixed second parameter

Why complex landing gears are used instead of simple, reliable and light weight muscle wire or shape memory alloys?

Calculation of line of sight system gain

Why not use the yoke to control yaw, as well as pitch and roll?

Are there any irrational/transcendental numbers for which the distribution of decimal digits is not uniform?

First paper to introduce the "principal-agent problem"

3D Masyu - A Die

How do you cope with tons of web fonts when copying and pasting from web pages?

Weaponising the Grasp-at-a-Distance spell

How can I prevent/balance waiting and turtling as a response to cooldown mechanics



Lowest TCP receive window size



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
Data science time! April 2019 and salary with experience
The Ask Question Wizard is Live!How to enable TCP_QUICKACK optionHow can I connect to Android with ADB over TCP?Who is listening on a given TCP port on Mac OS X?What is the maximum window size in segments of a TCP connection?Increasing TCP Window SizeBenefit of small TCP receive window?tcp receive window updateTCP receive window and congestion windowTCP receiving window size higher than net.core.rmem_maxHow is the window scale set/calculated in the TCP/IP implementation of the Linux kernel?Window Size when sender is faster than the receiver



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








0















What is the lowest possible TCP receive window size can be announced by Linux kernel TCP/IP stack impl and how can i configure to make it announce such one? My goal is to achieve low latency and sacrificing throughput?










share|improve this question






















  • Why do you think that reducing the TCP receive window size reduces latency?

    – Maxim Egorushkin
    Mar 22 at 14:07











  • For low latency you should be using UDP with kernel bypass.

    – Maxim Egorushkin
    Mar 22 at 14:08











  • "For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.

    – hwasin
    Mar 22 at 14:40


















0















What is the lowest possible TCP receive window size can be announced by Linux kernel TCP/IP stack impl and how can i configure to make it announce such one? My goal is to achieve low latency and sacrificing throughput?










share|improve this question






















  • Why do you think that reducing the TCP receive window size reduces latency?

    – Maxim Egorushkin
    Mar 22 at 14:07











  • For low latency you should be using UDP with kernel bypass.

    – Maxim Egorushkin
    Mar 22 at 14:08











  • "For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.

    – hwasin
    Mar 22 at 14:40














0












0








0


1






What is the lowest possible TCP receive window size can be announced by Linux kernel TCP/IP stack impl and how can i configure to make it announce such one? My goal is to achieve low latency and sacrificing throughput?










share|improve this question














What is the lowest possible TCP receive window size can be announced by Linux kernel TCP/IP stack impl and how can i configure to make it announce such one? My goal is to achieve low latency and sacrificing throughput?







sockets tcp network-programming






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Mar 22 at 12:40









hwasinhwasin

12




12












  • Why do you think that reducing the TCP receive window size reduces latency?

    – Maxim Egorushkin
    Mar 22 at 14:07











  • For low latency you should be using UDP with kernel bypass.

    – Maxim Egorushkin
    Mar 22 at 14:08











  • "For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.

    – hwasin
    Mar 22 at 14:40


















  • Why do you think that reducing the TCP receive window size reduces latency?

    – Maxim Egorushkin
    Mar 22 at 14:07











  • For low latency you should be using UDP with kernel bypass.

    – Maxim Egorushkin
    Mar 22 at 14:08











  • "For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.

    – hwasin
    Mar 22 at 14:40

















Why do you think that reducing the TCP receive window size reduces latency?

– Maxim Egorushkin
Mar 22 at 14:07





Why do you think that reducing the TCP receive window size reduces latency?

– Maxim Egorushkin
Mar 22 at 14:07













For low latency you should be using UDP with kernel bypass.

– Maxim Egorushkin
Mar 22 at 14:08





For low latency you should be using UDP with kernel bypass.

– Maxim Egorushkin
Mar 22 at 14:08













"For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.

– hwasin
Mar 22 at 14:40






"For low latency you should be using UDP with kernel bypass" - At this moment server accept TCP connections only. "Why do you think that reducing the TCP receive window size reduces latency?" - Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.

– hwasin
Mar 22 at 14:40













1 Answer
1






active

oldest

votes


















1















Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.




I do not think that changing the receive window size will have any effect on latency.



However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:




Applications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use TCP_NODELAY to bypass the Nagle delay.




On the receiver you may like to disable TCP delayed acknowledgements:




The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle's algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a TCP_QUICKACK socket option that disables delayed ACK.




C++ code:



void disableTcpNagle(int sock) 
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_NODELAY)");


void enableTcpQuickAck(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_QUICKACK)");






share|improve this answer

























  • I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.

    – hwasin
    Mar 22 at 14:58











  • @hwasin Added TCP_QUICKACK note for you.

    – Maxim Egorushkin
    Mar 22 at 15:01











  • Thank you. I tried this option and still receiver windows size is not reduced. Please see this question

    – hwasin
    Mar 22 at 15:05











  • @hwasin TCP_QUICKACK has nothing to do with the receivers window size. The receive window size is controlled by SO_RCVBUF socket option.

    – Maxim Egorushkin
    Mar 22 at 15:06












  • But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.

    – hwasin
    Mar 22 at 15:14











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
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
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55299828%2flowest-tcp-receive-window-size%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









1















Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.




I do not think that changing the receive window size will have any effect on latency.



However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:




Applications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use TCP_NODELAY to bypass the Nagle delay.




On the receiver you may like to disable TCP delayed acknowledgements:




The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle's algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a TCP_QUICKACK socket option that disables delayed ACK.




C++ code:



void disableTcpNagle(int sock) 
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_NODELAY)");


void enableTcpQuickAck(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_QUICKACK)");






share|improve this answer

























  • I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.

    – hwasin
    Mar 22 at 14:58











  • @hwasin Added TCP_QUICKACK note for you.

    – Maxim Egorushkin
    Mar 22 at 15:01











  • Thank you. I tried this option and still receiver windows size is not reduced. Please see this question

    – hwasin
    Mar 22 at 15:05











  • @hwasin TCP_QUICKACK has nothing to do with the receivers window size. The receive window size is controlled by SO_RCVBUF socket option.

    – Maxim Egorushkin
    Mar 22 at 15:06












  • But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.

    – hwasin
    Mar 22 at 15:14















1















Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.




I do not think that changing the receive window size will have any effect on latency.



However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:




Applications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use TCP_NODELAY to bypass the Nagle delay.




On the receiver you may like to disable TCP delayed acknowledgements:




The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle's algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a TCP_QUICKACK socket option that disables delayed ACK.




C++ code:



void disableTcpNagle(int sock) 
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_NODELAY)");


void enableTcpQuickAck(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_QUICKACK)");






share|improve this answer

























  • I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.

    – hwasin
    Mar 22 at 14:58











  • @hwasin Added TCP_QUICKACK note for you.

    – Maxim Egorushkin
    Mar 22 at 15:01











  • Thank you. I tried this option and still receiver windows size is not reduced. Please see this question

    – hwasin
    Mar 22 at 15:05











  • @hwasin TCP_QUICKACK has nothing to do with the receivers window size. The receive window size is controlled by SO_RCVBUF socket option.

    – Maxim Egorushkin
    Mar 22 at 15:06












  • But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.

    – hwasin
    Mar 22 at 15:14













1












1








1








Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.




I do not think that changing the receive window size will have any effect on latency.



However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:




Applications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use TCP_NODELAY to bypass the Nagle delay.




On the receiver you may like to disable TCP delayed acknowledgements:




The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle's algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a TCP_QUICKACK socket option that disables delayed ACK.




C++ code:



void disableTcpNagle(int sock) 
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_NODELAY)");


void enableTcpQuickAck(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_QUICKACK)");






share|improve this answer
















Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I'd like to make my client announce window size lower than SO_RCVBUF/2 if its possible.




I do not think that changing the receive window size will have any effect on latency.



However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:




Applications that expect real-time responses and low latency can react poorly with Nagle's algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use TCP_NODELAY to bypass the Nagle delay.




On the receiver you may like to disable TCP delayed acknowledgements:




The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle's algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a TCP_QUICKACK socket option that disables delayed ACK.




C++ code:



void disableTcpNagle(int sock) 
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_NODELAY)");


void enableTcpQuickAck(int sock)
int value = 1;
if(::setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof value))
throw std::system_error(errno, std::system_category(), "setsockopt(TCP_QUICKACK)");







share|improve this answer














share|improve this answer



share|improve this answer








edited Mar 22 at 15:01

























answered Mar 22 at 14:45









Maxim EgorushkinMaxim Egorushkin

90.7k11104193




90.7k11104193












  • I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.

    – hwasin
    Mar 22 at 14:58











  • @hwasin Added TCP_QUICKACK note for you.

    – Maxim Egorushkin
    Mar 22 at 15:01











  • Thank you. I tried this option and still receiver windows size is not reduced. Please see this question

    – hwasin
    Mar 22 at 15:05











  • @hwasin TCP_QUICKACK has nothing to do with the receivers window size. The receive window size is controlled by SO_RCVBUF socket option.

    – Maxim Egorushkin
    Mar 22 at 15:06












  • But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.

    – hwasin
    Mar 22 at 15:14

















  • I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.

    – hwasin
    Mar 22 at 14:58











  • @hwasin Added TCP_QUICKACK note for you.

    – Maxim Egorushkin
    Mar 22 at 15:01











  • Thank you. I tried this option and still receiver windows size is not reduced. Please see this question

    – hwasin
    Mar 22 at 15:05











  • @hwasin TCP_QUICKACK has nothing to do with the receivers window size. The receive window size is controlled by SO_RCVBUF socket option.

    – Maxim Egorushkin
    Mar 22 at 15:06












  • But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.

    – hwasin
    Mar 22 at 15:14
















I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.

– hwasin
Mar 22 at 14:58





I agree with your commentary, but the problem is that i dont have access to server and i'd like to know whether its even possible technically to enforce kernel announce lower TCP window on client side.

– hwasin
Mar 22 at 14:58













@hwasin Added TCP_QUICKACK note for you.

– Maxim Egorushkin
Mar 22 at 15:01





@hwasin Added TCP_QUICKACK note for you.

– Maxim Egorushkin
Mar 22 at 15:01













Thank you. I tried this option and still receiver windows size is not reduced. Please see this question

– hwasin
Mar 22 at 15:05





Thank you. I tried this option and still receiver windows size is not reduced. Please see this question

– hwasin
Mar 22 at 15:05













@hwasin TCP_QUICKACK has nothing to do with the receivers window size. The receive window size is controlled by SO_RCVBUF socket option.

– Maxim Egorushkin
Mar 22 at 15:06






@hwasin TCP_QUICKACK has nothing to do with the receivers window size. The receive window size is controlled by SO_RCVBUF socket option.

– Maxim Egorushkin
Mar 22 at 15:06














But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.

– hwasin
Mar 22 at 15:14





But if TCP_QUICKACK option is enabled and hence my 128 bytes ACKnowledgment should be delivered to server then client should announce 128 byte receiver window too, but kernel does not do that, it waits till SO_RCVBUF/2 window size can be announced.

– hwasin
Mar 22 at 15:14



















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • 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.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55299828%2flowest-tcp-receive-window-size%23new-answer', 'question_page');

);

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







Popular posts from this blog

Kamusi Yaliyomo Aina za kamusi | Muundo wa kamusi | Faida za kamusi | Dhima ya picha katika kamusi | Marejeo | Tazama pia | Viungo vya nje | UrambazajiKuhusu kamusiGo-SwahiliWiki-KamusiKamusi ya Kiswahili na Kiingerezakuihariri na kuongeza habari

SQL error code 1064 with creating Laravel foreign keysForeign key constraints: When to use ON UPDATE and ON DELETEDropping column with foreign key Laravel error: General error: 1025 Error on renameLaravel SQL Can't create tableLaravel Migration foreign key errorLaravel php artisan migrate:refresh giving a syntax errorSQLSTATE[42S01]: Base table or view already exists or Base table or view already exists: 1050 Tableerror in migrating laravel file to xampp serverSyntax error or access violation: 1064:syntax to use near 'unsigned not null, modelName varchar(191) not null, title varchar(191) not nLaravel cannot create new table field in mysqlLaravel 5.7:Last migration creates table but is not registered in the migration table

은진 송씨 목차 역사 본관 분파 인물 조선 왕실과의 인척 관계 집성촌 항렬자 인구 같이 보기 각주 둘러보기 메뉴은진 송씨세종실록 149권, 지리지 충청도 공주목 은진현