Feature request...?

[Andre Grueneberg]

Hi Nick

Nick Andre schrieb:

AG>> NA> Is it possible for BinkD to "busy out" and refuse ALL incoming
AG>> NA> connections by setting a semaphore file of some kind?
AG>> What do you mean by "busy out"? Currently there is no such
AG>> functionality -- well, I believe you could do some of it using
AG>> integrated Perl though.
NA> For example, when the "max servers" setting is exceeded, any
NA> further incoming connections are denied and the remote system
NA> returns a "Busy" status (Irex)

In a multi-process environment binkd currently does not know about the number
of open connections. In a multi-threaded environment (Windows and OS/2) one
could implement such checks.

So it's rather not about some semaphore file, but about the number of
connections. Otherwise there'd be the question "how do you implement the
semaphore creation/deletion?".

You could use on_call() and on_handshake() Perl hooks to implement what you
want.

AG>> What's the rationale behind this anyway? So far I don't see the
AG>> point what you'd like to accomplish? I'd say, you could stop the
AG>> daemon and start it again when your whatever-maintenance is over?!
NA> No I do not want to stop the daemon as that may cause problems for
NA> systems who connect again on a high traffic server system which
NA> moves a lot of mail. I want to busy-out any new incoming
NA> connections and prevent any further ongoing ones.

It shouldn't be too hard to implement some semaphore file handling on
connection accept, but so far I don't see much value in that ... if there were
more people requesting it, I'd start implementing it though...

CU Andre E-Mail: ***@grueneberg.de

[Pavel Gulchouck]

Hi Andre!

06 Aug 12, Andre Grueneberg ==> Nick Andre:

AG>>> NA> Is it possible for BinkD to "busy out" and refuse ALL incoming
AG>>> NA> connections by setting a semaphore file of some kind?
AG>>> What do you mean by "busy out"? Currently there is no such
AG>>> functionality -- well, I believe you could do some of it using
AG>>> integrated Perl though.
NA>> For example, when the "max servers" setting is exceeded, any
NA>> further incoming connections are denied and the remote system
NA>> returns a "Busy" status (Irex)

AG> In a multi-process environment binkd currently does not know about the
AG> number of open connections. In a
AG> multi-threaded environment (Windows and OS/2) one could implement such
AG> checks.

It's implemented for both multi-process and multi-thread environment.
See "maxclients" and "maxservers" config directives.

AG>>> What's the rationale behind this anyway? So far I don't see the
AG>>> point what you'd like to accomplish? I'd say, you could stop the
AG>>> daemon and start it again when your whatever-maintenance is over?!

NA>> No I do not want to stop the daemon as that may cause problems for
NA>> systems who connect again on a high traffic server system which
NA>> moves a lot of mail. I want to busy-out any new incoming
NA>> connections and prevent any further ongoing ones.

AG> It shouldn't be too hard to implement some semaphore file handling on
AG> connection accept, but so far I don't see much
AG> value in that ... if there were more people requesting it, I'd start
AG> implementing it though...

It's possible to run binkd on incoming connections via xinetd which can control
rate of connections, load average, number of running servers and other stuff.

Lucky carrier,
Pavel
aka ***@gul.kiev.ua

[Andre Grueneberg]

Hi Pavel

Pavel Gulchouck schrieb:

AG>> In a multi-process environment binkd currently does not know
AG>> about the number of open connections. In a multi-threaded
AG>> environment (Windows and OS/2) one could implement such
AG>> checks.
PG> It's implemented for both multi-process and multi-thread
PG> environment. See "maxclients" and "maxservers" config directives.

Okay ... the directives indeed exist. From looking at the code, I never see the
servmgr process decreasing n_servers ... I haven't verified this though.
Loglevel 5+ should reveal what's going on ...

CU Andre E-Mail: ***@grueneberg.de

[Andre Grueneberg]

Hi Pavel

Andre Grueneberg schrieb:

PG>> It's implemented for both multi-process and multi-thread
PG>> environment. See "maxclients" and "maxservers" config directives.
AG> Okay ... the directives indeed exist. From looking at the code, I
AG> never see the servmgr process decreasing n_servers ... I haven't
AG> verified this though. Loglevel 5+ should reveal what's going on ...

Okay ... found it now ... the SIGCHLD handling is a bit distributed and not
very obvious. ;)
Indeed counting child processes does work as one would expect.

CU Andre E-Mail: ***@grueneberg.de