Christian Ro??ner:
> Hi,
>
> I just looked into the socketmap_table man page. I try to understand several
> things:
>
> First: Is it correct that request and response are not terminated by newline?
I think that is the least of your problems.
This is not a text-based protocol where messages are terminated
with some end-of-line character.
Instead this uses netstrings, which encode message boundaries with
byte counts. You may have some additional coding ahead of you.
> Second the respone:
>
> OK <space> data
> The requested data was found.
>
> NOTFOUND <space>
> The requested data was not found.
>
> TEMP <space> reason
>
> TIMEOUT <space> reason
>
> PERM <space> reason
> The request failed. The reason, if non-empty, is descriptive
> text.
>
> Which of these return values do work with postscreen_access_list?
None of them. The OK, NOTFOUND, etc. are part of the socketmap
protocol. They are never visible to the postscreen_access_list.
> Could someone give me an example please :-) ?
You need ti distinguish between:
1 - Table-driven mechanisms, for example, transport_maps or
postscreen_access_list. These use simple key-value API that
is exposed by things in [2].
2 - Table lookup mechanisms, for example, hash, mysql, or socketmap.
These expose a simple key-value API that is used by things in [1].
Under the covers, table lookup mechanisms encapsulate those
keys and values as "name <space> key" or "SELECT 'foo' FROM
bar" depending on whether they talk to a socketmap server or
to an SQL server, but that is never visible to things in [1].
> As the response tokens are not described in detail, I ask for help here.
They are. You just need to combine the postcreen_access_list
documentation with the socketmap encapsulation.
> OK <space> permit (or dunno)
> NOTFOUND <space>
> TEMP <space> What is done with this reason?
It is up to the table-driven mechanism to report it as a warning
or to report it as a fatal error.
Wietse
