10 Nov
2005
10 Nov
'05
5:16 p.m.
Hi Klaus,
Klaus Darilion wrote:
ok :)
yes, makes sense
the idea behind was to move the functionality of load_gw and next_gw
into core to allow a standard mechanism for serial forking for all
modules (without interdependencies).
Enum, registrar, NAPTR lookup, etc will be able to do serial forking
also without depending of lcr module.
can you extract the patch ;)?
regards,
bogdan
Daniel-Constantin Mierla wrote:
first step will be only NAPTR lookup and interpretation of priorities,
protocols, etc.
- generic communication interface which must
offer an abstract layer
between
core/modules and transports (e.g., fifo, unix sockets)
- move the code of the implemented trasports as module
- NAPTR lookup
with failover to next server/protocol? interpret ICMP error messages - TLS multi-domain support
- TLS configuration values to be set via a module, to keep core less
exposed
I will write a separe emails for my TLS ideas :-) - security checks of destination addess
(white/black lists)
maybe not only based on IP address, but IP address, port and protocol
(which may be also * for all ports/protocols) [enum]
[-] - parallel/serial forking based on order and preference fields
isn't this already possible using load_gw, next_gw?
[postgres]
- connection pool
- shift to memory manager used by openser
there was a big patch by jan for ser - maybe we can use this patch.