in reply to Re^2: changing tcp parameters when establishing connection
in thread changing tcp parameters when establishing connection

This depends very much on your OS defaults and any distro-level or admin-level tuning. The actual definition of buffer window and receive size are frequently set to the maximum possible size by implementations, but you can adjust this in the application level. I merely said this has an impact on the TCP-window size, per the manpage reference I gave earlier.

Remember, the stock Linux or BSD kernel defaults can be adjusted by kernel maintainers (changing official upstream options,) by an admin who uses knobs like sysctl tuning to adjust defaults, or by applications that have some say over userland tooling (such as the socket-level options we're discussing here.) I can't tell you exactly what impact your change to the SO_RECVBUF size will have since I do not know the defaults on your current system. Use the above resources to find out, or learn more about them. Remember, sometimes you get a bit "dirty" learning how all the layers in an modern system interact. Test and see what the impact is for you.

Finally, note that the definitive reference for Window Scaling is RFC-1323. Specifically, section 2.1 talks about the need for buffer sizes large enough to make window-scaling effective. This is probably why the API documentation for tcp on various platforms frequently mentions this fact. It's quite possible your kernel/sysctl/userland is already using the "largest possible" buffers, in which case the behavior your noted may be quite correct. This may not be the case on someone else's OS, distro, or configuration.

FYI, your code is a bit hard to read; use <code> tags to increase readability by printing the code as you wrote it (markup docs are helpful too.)

Replies are listed 'Best First'.
Re^4: changing tcp parameters when establishing connection
by BrowserUk (Patriarch) on Dec 03, 2015 at 17:18 UTC
    but you can adjust this in the application level.

    Sorry, but that is wrong. The tcp window size & scaling parameters are tcp-stack-wide parameters.

    If one application causes them to change dynamically -- only possible if it has admin privileges; if then -- then that change would affect all applications -- system and user -- using tcpip.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      Update2: I'm not sure why this is getting downvotes, but my technical information is very much correct. I have included a script that can impact the TCP Window size scaling factor at the end of this comment. Not sure why correct technical information is being downvoted, but at the possibility of getting more negative votes, I'm including full demonstration code that shows this is accurate at the end of this post. /Update2

      Sorry, but that is clearly not what the RFC I linked to said. Quoting here:

      The maximum receive window, and therefore the scale factor, is determined by the maximum receive buffer space. In a typical modern implementation, this maximum buffer space is set by default but can be overridden by a user program before a TCP connection is opened. This determines the scale factor, and therefore no user interface is needed for window scaling.

      Update: So, breaking this down, the above quote says "the scaling factor is determined by the buffer space, which the application has access do. Thus we do not need to give the userland API additional control over further tuning on top of kernel support." /Update

      Notice the one important piece here: userland applications can take advantage of window-scaling (again, provided the administrator and kernel are configured for such support, which I have mentioned several times now,) without needing any additional API.

      Perhaps I am mis-understanding the point of contention for you, but you seem to be suggesting that there is no API that can control this. The RFC, and system-documentation, says otherwise. Obviously if the feature is disabled in the kernel or by the admin, one cannot have it. However, reading the RFC, it's possible for an application to avoid window-scaling by setting the buffers small enough that the kernel will not enable that feature.

      I never said an application got to set kernel-wide params. I point out last comment and again here that they have an impact on it. It is very possible to change the buffers (which are socket-level options) which do have an impact on the window-scaling. Again, reference the quote above and the tcp manpage, referenced earlier in the thread.

      Part of Update2: Code follows that shows you can impact the window-scaling factor from userland follows. If nothing else, this should help others understand how socket code works and what control userland has over the process.

      Read more... (4 kB)
[reply]
[d/l]
[select]

        What you are describing is this:

        1. If your tcpip stack supports window scaling;
        2. And if it is enabled for your machine and your userid/group;
        3. And if you set the receive buffer size immediately after connect
        4. And if the remote host tcpip stack also supports window scaling;
        5. And if it is enabled;
        6. And if all the firewalls, gateway devices and bridges between the ends support window scaling; have it enabled and are set to monitor the scaling factors;
        7. And if the bandwidth-delay product between them indicates a benefit from increasing the buffer size;
        8. And if the application retrieve rate is sufficiently high to merit it;
        9. And if the stack-wide maximum scaling factor permits it;

        Then setting the receive buffer size may, heuristically allow an application to influence the setting of the window size/scale factor product.

        That's an awful lot of ifs & buts, to be claiming "an application can set the window size".

        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom