Quantcast

TIP #468: Support Passing TCP listen Backlog Size Option to TCP Socket Creation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

TIP #468: Support Passing TCP listen Backlog Size Option to TCP Socket Creation

Shannon Noe

 TIP #468: SUPPORT PASSING TCP LISTEN BACKLOG SIZE OPTION TO TCP SOCKET CREATION
=================================================================================
 Version:      $Revision: 1.1 $
 Author:       Shannon Noe <shannon.noe_at_flightaware.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.7
 Vote:         Pending
 Created:      Monday, 03 April 2017
 URL:          http://purl.org/tcl/tip/468.html
 WebEdit:      http://purl.org/tcl/tip/edit/468
 Post-History:

-------------------------------------------------------------------------

 ABSTRACT
==========

 This TIP adds the ability to control the TCP backlog depth used by the
 /listen/ system call within the *socket* Command. The API function,
 *Tcl_OpenTcpServerEx*, will be extended to allow the passing of the
 backlog value. Currently, the SOMAXCONN macro is used as the default.
 Backlog values are hard coded to a minimum of 100. The backlog values
 of 1 and 0 are useful on the Linux platform.

 RATIONALE
===========

 Modern Linux TCP supports the kernel managing the listen queue for TCP
 sockets. Multiple processes open the same socket address and ports with
 SOREUSEADDR and SOREUSEPORT. Each process then uses a backlog value of
 1 to process a single connection at a time. This is explained in detail
 on this website
 <URL:http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html>

 Tighter control over this would allow Tcl scripts to have tighter
 control over whether to support a large backlog of sockets waiting to
 be opened. (Exceeding the limit would cause the OS to automatically
 reject the socket connection, which might be preferable in some
 high-availability situations to being blocked for an unknown amount of
 time.)

 SPECIFICATION
===============

 A *Tcl_OpenTcpServerEx* function will be changed to add a /backlog/
 parameter with this signature:

       Tcl_Channel *Tcl_OpenTcpServerEx*(Tcl_Interp */interp/, const
       char * /service/, const char */myHost/, unsigned int /flags/, int
       /backlog/, Tcl_TcpAcceptProc */acceptProc/, ClientData
       /acceptProcData/)

 As for the Tcl side, the *socket* command gains a new optional switch
 that are only valid for server sockets: ?*-backlog* /int/?. Omitting
 the parameter will cause the default value to be used.

 Tcl code includes local macroâ[™s for SOMAXCONN which override all
 platforms values for SOMAXCONN. This makes backwards compatibility
 easier. We only need to preserve the macro value in the default code
 path.

 REFERENCE IMPLEMENTATION
==========================

 Please refer to the /tip-???/ branch of the core Tcl repository.

 BACKWARDS COMPATIBILITY
=========================

 The *Tcl_OpenTcpServerEx* will retain the old behavior by default as
 SOMAXCONN. The SOMAXCONN is defined by macros in the Tcl source. All
 Tcl code paths with a listen() system call pass a backlog value. No new
 code paths are introduced, only new values for the listen backlog
 parameter.

 The *socket* command will be backwards compatible. The default
 *-backlog* parameter is set to /SOMAXCONN/. Omission of the new
 parameter provides the current behavior.

 COPYRIGHT
===========

 This document has been placed in the public domain.

-------------------------------------------------------------------------

 TIP AutoGenerator - written by Donal K. Fellows

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TIP #468: Support Passing TCP listen Backlog Size Option to TCP Socket Creation

Alexandre Ferrieux
On Sun, Apr 9, 2017 at 12:35 PM, Shannon Noe
<[hidden email]> wrote:

>
>  TIP #468: SUPPORT PASSING TCP LISTEN BACKLOG SIZE OPTION TO TCP SOCKET CREATION
> =================================================================================
>  A *Tcl_OpenTcpServerEx* function will be changed to add a /backlog/
>  parameter with this signature:
>
>        Tcl_Channel *Tcl_OpenTcpServerEx*(Tcl_Interp */interp/, const
>        char * /service/, const char */myHost/, unsigned int /flags/, int
>        /backlog/, Tcl_TcpAcceptProc */acceptProc/, ClientData
>        /acceptProcData/)

Hum, you're right, it's unfortunate that the recent creation of
Tcl_OpenTcpServerEx (TIP #456) was shy enough to only add a bitmask
(flags), leaving no room for things like the listen() argument.
Good job ; let's do it quickly, to minimize the incompatibility window ;)

-Alex

PS: it would be cool to be sure there is no other popular tweak
lurking in the dark until this one goes final :)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TIP #468: Support Passing TCP listen Backlog Size Option to TCP Socket Creation

Harald Oehlmann
Am 09.04.2017 um 13:22 schrieb Alexandre Ferrieux:

> On Sun, Apr 9, 2017 at 12:35 PM, Shannon Noe
> <[hidden email]> wrote:
>>
>>  TIP #468: SUPPORT PASSING TCP LISTEN BACKLOG SIZE OPTION TO TCP SOCKET CREATION
>> =================================================================================
>>  A *Tcl_OpenTcpServerEx* function will be changed to add a /backlog/
>>  parameter with this signature:
>>
>>        Tcl_Channel *Tcl_OpenTcpServerEx*(Tcl_Interp */interp/, const
>>        char * /service/, const char */myHost/, unsigned int /flags/, int
>>        /backlog/, Tcl_TcpAcceptProc */acceptProc/, ClientData
>>        /acceptProcData/)
>
> Hum, you're right, it's unfortunate that the recent creation of
> Tcl_OpenTcpServerEx (TIP #456) was shy enough to only add a bitmask
> (flags), leaving no room for things like the listen() argument.
> Good job ; let's do it quickly, to minimize the incompatibility window ;)
>
> -Alex
>
> PS: it would be cool to be sure there is no other popular tweak
> lurking in the dark until this one goes final :)


Alex,
thank you for asking about "additional needs". When reworking the win
socket, there was the need of some test flags:

In 2014, I wanted to add some tests in the internals of a socket and
needed to pass that information.
The result was branch: robust-async-connect-tests
https://core.tcl.tk/tcl/timeline?r=robust-async-connect-tests&nd&c=2014-07-17+09%3A53%3A36&n=200

which never found its way into trunk.

I think, things might be easier, if there would be test modes flags
available for the socket calls, instead using the method here to access
directly the socket array.

The corresponding thread on the core list was titled "How to pass a test
flag to the socket channel driver?", with the key post by Donal:

Am 15.07.2014 um 12:44 schrieb Donal K. Fellows:

> On 14/07/2014 14:32, Harald Oehlmann wrote:
>>   (1) + (2) : no go IMHO -> no way to set a flag in driver by C
>
> What? No! Tcl_GetChannelInstanceData() will return a handle to the
> per-instance type-specific structure, which the test code will know the
> type of and so be able to poke around inside. You'll have to be careful
> with threads if you're doing complicated messing around with them, but
> otherwise you'll be just fine.
>
> Donal.

So, this might be a condidate ?

Thank you,
Harald

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TIP #468: Support Passing TCP listen Backlog Size Option to TCP Socket Creation

Jan Nijtmans-2
2017-04-10 11:42 GMT+02:00 Harald Oehlmann:

 In 2014, I wanted to add some tests in the internals of a socket and
> needed to pass that information.
> The result was branch: robust-async-connect-tests
> https://core.tcl.tk/tcl/timeline?r=robust-async-connect-tests&nd&c=2014-07-17+09%3A53%3A36&n=200
>
> which never found its way into trunk.

Now it did! I tested it, and I think it's a good idea, much better
than making a test-case "nonPortable"!
   <https://core.tcl.tk/tcl/info/9f162eb401c88fc4>

At that time, "trunk" was still for 8.6 development, that's why
I hesitated at that time: I wouldn't like the possibility for
bug-reports on existing test-cases that start failing.

Thanks!
     Jan Nijtmans

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TIP #468: Support Passing TCP listen Backlog Size Option to TCP Socket Creation

Harald Oehlmann
Am 10.04.2017 um 14:44 schrieb Jan Nijtmans:

> 2017-04-10 11:42 GMT+02:00 Harald Oehlmann:
>
>  In 2014, I wanted to add some tests in the internals of a socket and
>> needed to pass that information.
>> The result was branch: robust-async-connect-tests
>> https://core.tcl.tk/tcl/timeline?r=robust-async-connect-tests&nd&c=2014-07-17+09%3A53%3A36&n=200
>>
>> which never found its way into trunk.
>
> Now it did! I tested it, and I think it's a good idea, much better
> than making a test-case "nonPortable"!
>    <https://core.tcl.tk/tcl/info/9f162eb401c88fc4>
>
> At that time, "trunk" was still for 8.6 development, that's why
> I hesitated at that time: I wouldn't like the possibility for
> bug-reports on existing test-cases that start failing.
>
> Thanks!
>      Jan Nijtmans
>

Thank you, Jan, this answer surprises me ;-).

O.K., it is back alive.

Thanks,
Harald


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TIP #468: Support Passing TCP listen Backlog Size Option to TCP Socket Creation

Michael Schlenker-5
In reply to this post by Alexandre Ferrieux
Hi Alex,

> Gesendet: Sonntag, 09. April 2017 um 13:22 Uhr
> Von: "Alexandre Ferrieux" <[hidden email]>
> An: TclCore <[hidden email]>
> Cc: "Shannon Noe" <[hidden email]>
> Betreff: Re: [TCLCORE] TIP #468: Support Passing TCP listen Backlog Size Option to TCP Socket Creation
>
> On Sun, Apr 9, 2017 at 12:35 PM, Shannon Noe
> <[hidden email]> wrote:
> >
> >  TIP #468: SUPPORT PASSING TCP LISTEN BACKLOG SIZE OPTION TO TCP SOCKET CREATION
> > =================================================================================
> >  A *Tcl_OpenTcpServerEx* function will be changed to add a /backlog/
> >  parameter with this signature:
> >
> >        Tcl_Channel *Tcl_OpenTcpServerEx*(Tcl_Interp */interp/, const
> >        char * /service/, const char */myHost/, unsigned int /flags/, int
> >        /backlog/, Tcl_TcpAcceptProc */acceptProc/, ClientData
> >        /acceptProcData/)
>
> Hum, you're right, it's unfortunate that the recent creation of
> Tcl_OpenTcpServerEx (TIP #456) was shy enough to only add a bitmask
> (flags), leaving no room for things like the listen() argument.
> Good job ; let's do it quickly, to minimize the incompatibility window ;)
>
> -Alex
>
> PS: it would be cool to be sure there is no other popular tweak
> lurking in the dark until this one goes final :)
>
some useful options for socket creation (because they cannot be used later, once the socket is already listening/bound).

Windows sockoptions:
SO_EXCLUSIVEADDRUSE  (unless that is included in the SO_REUSEADDR of TIP 456)

And for quite a performance boost to loopback only sockets on Windows (which are dead slow compared to Linux),
the IOCTL parameter SIO_LOOPBACK_FAST_PATH which needs to be used before the socket is bound (on client + server side).

See https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path/
https://msdn.microsoft.com/en-us/library/windows/desktop/jj841212(v=vs.85).aspx

Especially the FAST_PATH stuff has been added to various other languages (Python 3.6, Java), so guess it can be called popular.

Michael

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TIP #468: Support Passing TCP listen Backlog Size Option to TCP Socket Creation

Alexandre Ferrieux
Hi Michael,

On Mon, Apr 10, 2017 at 8:03 PM,  <[hidden email]> wrote:

> Hi Alex,
>
>>
>> PS: it would be cool to be sure there is no other popular tweak
>> lurking in the dark until this one goes final :)
>>
> some useful options for socket creation (because they cannot be used later, once the socket is already listening/bound).
>
> Windows sockoptions:
> SO_EXCLUSIVEADDRUSE  (unless that is included in the SO_REUSEADDR of TIP 456)
>
> And for quite a performance boost to loopback only sockets on Windows (which are dead slow compared to Linux),
> the IOCTL parameter SIO_LOOPBACK_FAST_PATH which needs to be used before the socket is bound (on client + server side).
>
> See https://blogs.technet.microsoft.com/wincat/2012/12/05/fast-tcp-loopback-performance-and-low-latency-with-windows-server-2012-tcp-loopback-fast-path/
> https://msdn.microsoft.com/en-us/library/windows/desktop/jj841212(v=vs.85).aspx
>
> Especially the FAST_PATH stuff has been added to various other languages (Python 3.6, Java), so guess it can be called popular.
>
> Michael

Interesting. So, the "goodies" that we'd like to address are those
that cannot be set up later (e.g. in [fconfigure]) because they're
based on seteockopt() between socket creation and binding:

      socket(); SECTION1 ; listen(); SECTION2 ; bind()

Beyond enumerating the goodies and their constraints ("belongs to
SECTIONx"), it seems that we have two options:

 (a) be as exhaustive as possible, and extend Tcl_OpenTcpServerEx once
for all, with enough extra parameters to cope for everything. All
boolean things should easily fit in the already existing "flags"; but
TIP468's backlog arg may not be the only necessary int...

 (b) design a generic extension method. Future additions will use it
but will never need a signature change for Tcl_OpenTcpServerEx.
Examples:  hooks ; array of (long) ; hostname pollution.

Of course, if the collection of goodies deemed to be worth the effort
is only {SO_REUSEADDR SO_REUSEPORT backlog}, then (a) is the way to
go, and TIP 468 is the end of the story.

On the other hand, if what you suggest, or other stuff like
SO_BINDTODEVICE, are matched with a real need, (b) needs some thought.

Thoughts ?

-Alex

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-core
Loading...