June 22, 2021 11:14 PM, "Aisha Tammy" <[email protected]> wrote:
>> [...]
>>
>> WRT to handshake, it has multiple uses ranging from ensuring the addons get
>> their configuration
>> from the daemon to synchronising the daemon start with addons readiness.
>> Remember, we didn’t have this with filters and realised we couldn’t do
>> without, it is the same for
>> tables, they need to get their “table name” at start so we need the daemon
>> to pass them, and we
>> also need the daemon to not start using them before they are ready.
>
> I am unsure what you mean by a handshake.
>
sure, so let's look at procexec for filters:
- when the server starts, it forks the filters and begins a handshake with each
of them,
emitting the following (for example):
config|smtpd-version|6.6.1
config|smtp-session-timeout|300
config|subsystem|smtp-in
config|ready
- when the filter receives the last line, it knows the server is done and it is
its turn,
it emits the following:
register|report|smtp-in|link-connect
register|ready
- at this point the handshake is over, the server is ready and the filter is
ready too,
they are both in a known state and synchronised before data flows to the
filter.
The procexec tables should have a similar handshake to allow the server to pass
them
information and make sure they are synchronised.
The only difference with filters would be that table would have a different
"register""
line in the handshake but the config part should be similar.
This would an addon to implement both a filter and a table by registering for
filtering,
and providing a lookup backend for example.
> Would something like the following be good - on exec the table process has to
> print out a string
> "TABLE-READY" which ensures us that the process is ready.
>
Almost, on exec the daemon prints the config bits (exactly like it does for
filter),
then it reads from the table backend for a register|ready,
but yes you have the idea.
> I am not exactly sure how I would implement this, my guess would be to use
> event(3) with EV_READ on
> backend_r (or something like that).
>
I haven't looked at this code in over a year now so I'm not sure what the right
way
of doing it is on top of my head, but looking at how filters are handled is a
good
startint point.
