Andreas Granig writes:
In short, I plan to write an xmlrpc-based provisioning
system for
distributing FIFO commands. The main focus is sharing registration
contacts and aliases among different SERs (all the data that can't be
replicated on a lower (database) layer due to memory caching).
is replication of register requests to other sers too slow for you?
regarding aliases, i don't use aliases table at all. i return the
possible aliases called user as reply items to radius_does_uri_exist
call.
There's an external application on each SER host
receiving contacts from
a SER module via a local socket. These contacts are wrapped into xmlrpc
(in fact the contact is converted into a FIFO command which is wrapped
into xmlrpc) and are distributed to the same application on other SER
hosts, which writes them into the SER FIFO. If an application is
unreachable or reports an error, the distributed FIFO command is
queued.
this is close to what i did when i wrote fifo server. separate fifo
server was supposed to be a temporary thing that can go away when ser
learns to receive fifo commands over tcp. i still think that it is a
bad idea to introduce a new process to the system that can go down
requiring queuing and other complexities. so why just not introduce tcp
support for ser fifo?
-- juha