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