See the following statement here [1]:

-------------
(4) In order to handle N concurrent connections on a Unix platform, stunnel requires nfile (ulimit -n) to be higher than 2*N, and nproc (ulimit -u) to be higher than N
-------------

I really don't understand why there is such a relationship: "In order to handle N concurrent connections on a Unix platform, stunnel requires nfile (ulimit -n) to be higher than 2*N".

Any hints will be highly appreciated.

[1] https://www.stunnel.org/perf.html

Regards,
HZ

On Mon, 20 Dec 2021 17:20:55 -0800, hongy...@gmail.com wrote:

> See the following statement here [1]:
>
> -------------
> (4) In order to handle N concurrent connections on a Unix platform,
> stunnel requires nfile (ulimit -n) to be higher than 2*N, and nproc
> (ulimit -u) to be higher than N -------------
>
> I really don't understand why there is such a relationship: "In order to
> handle N concurrent connections on a Unix platform, stunnel requires
> nfile (ulimit -n) to be higher than 2*N".
>
> Any hints will be highly appreciated.

Stunnel is a "load-balancing proxy", implying that relays traffic between
clents and servers. If there are N client connections, then stunnel will
require 2 * N connections, one for each of N client connections to
stunnel, and one for each of N corresponding stunnel connections to the
appropriate servers.

As each stunnel connection will consume a file descriptor, N client
connections will cause stunnel to consume 2 * N file descriptors, one for
each side of the proxy.

The Unix kernel places both hard and soft limits on a number of critical
resources, including how many file descriptors a process can have open at
any one time. The shell "ulimit" builtin allows you to manipulate some of
these limits (within reason).

The stunnel documentation is advising you that you may have to adjust the
maximum number of file descriptors a process may have open, so that
stunnel may operate as you intend it. The instructions tell you to
determine the maximum number of connections that stunnel will handle,
double that number, and use the resulting value as the maximum number of
file handles.

HTH
--
Lew Pitcher
"In Skills, We Trust"

On Tuesday, December 21, 2021 at 10:17:38 AM UTC+8, Lew Pitcher wrote:
> On Mon, 20 Dec 2021 17:20:55 -0800, hongy...@gmail.com wrote:
>
> > See the following statement here [1]:
> >
> > -------------
> > (4) In order to handle N concurrent connections on a Unix platform,
> > stunnel requires nfile (ulimit -n) to be higher than 2*N, and nproc
> > (ulimit -u) to be higher than N -------------
> >
> > I really don't understand why there is such a relationship: "In order to
> > handle N concurrent connections on a Unix platform, stunnel requires
> > nfile (ulimit -n) to be higher than 2*N".
> >
> > Any hints will be highly appreciated.
> Stunnel is a "load-balancing proxy", implying that relays traffic between
> clents and servers. If there are N client connections, then stunnel will
> require 2 * N connections, one for each of N client connections to
> stunnel, and one for each of N corresponding stunnel connections to the
> appropriate servers.
>
> As each stunnel connection will consume a file descriptor, N client
> connections will cause stunnel to consume 2 * N file descriptors, one for
> each side of the proxy.
>
> The Unix kernel places both hard and soft limits on a number of critical
> resources, including how many file descriptors a process can have open at
> any one time. The shell "ulimit" builtin allows you to manipulate some of
> these limits (within reason).
>
> The stunnel documentation is advising you that you may have to adjust the
> maximum number of file descriptors a process may have open, so that
> stunnel may operate as you intend it. The instructions tell you to
> determine the maximum number of connections that stunnel will handle,
> double that number, and use the resulting value as the maximum number of
> file handles.

Got it. I mistook 2 * N for another sign 2 ^ N, which puzzles most, so I asked this question.

HZ

On 12/21/21 2:00 AM, hongy...@gmail.com wrote:
> Got it. I mistook 2 * N for another sign 2 ^ N, which puzzles most,
> so I asked this question.

Oops.

Exponential growth (2^N) is decidedly different than linear growth (2xN).

--
Grant. . . .
unix || die