21 Jan
2005
21 Jan
'05
7:46 p.m.
I've changed to the serdev list, I think it's ontopic there.
Greger V. Teigre wrote:
DNS SRV. I think some kind of reference design using
Linux HA or
virtual server would be useful for the community. I have seen several
people asking questions, but I haven't seen documentation of a
successful implementation. The reference design must of course handle
NAT traversal and the possibility of RTP proxying.
Ack. I heard about people testing
http://www.linuxvirtualserver.org/software/ipvs.html with SER, but the
system design and the results are, well, closed.
yes, I see you here define a more general network
wrapper to the FIFO.
Why not extend the scope right now to support any FIFO implemented
command, also future?
Of course this should be possible.
If FIFO writing is not possible, I believe an alert
should be made
and the request left in a transaction queue. There is probably a reason
for the FIFO error and also writing directly to the database will mess
up the synch between DB and server.
I meant that when you definitely know that the SER is currently down you
could write directly to the database. On the other hand writing to the
DB would mean that you've to know the usrloc backend, so I agree that
this is not a good idea.
Bringing up new clients will of course need some
special thoughts in
terms of their status and at what point in replication they should
enter. Probably each transaction should use a unique transaction id...
Adding new SERs to a node isn't the common case I think. So I'd keep it
rather simple in the beginning and hardcode the peers in a file or
something like this. New contacts are automatically pushed to new nodes,
and the overall location table has to be pulled by the new node.
Just my opinion.
Why do you think SOAP should be dropped?
If this is to be a general module for both provisioning and
replication across servers, we must handle many different usage
scenarios, ex. provisioning over the Internet, and we should use a
framework where we can get as much as possible for "free", ex. SSL/TLS,
authentication etc.
In my experience, SOAP can be both simple and fast and there are far
more auto-generation tools/frameworks etc for SOAP. A simple RPC-type
SOAP message is not really far from XML-RPC, basically an envelope
extra. The ability to auto-generate a client based on a WSDL file is
pretty nice, as well.
I didn't perform a benchmark, just asked the mailserver guys here who
use SOAP for provisioning, and they say it's ok for a few requests per
second, but it will not perform for, say, 100 requests per second.
I have here contributed to increasing the scope... But
I think the
correct approach would be to make something simple in the beginning,
maybe only the provisioning and the queue and a text-based config file
for clients to replicate to. We could then add the ser module for
forwarding usrloc to the local client.
My current status is:
I've written a SER module that hooks into the usrloc module by using the
existing callback mechanism. On each change of a contact (insert,
update, delete, expire) the module connects via UNIX socket to a
external client and serializes the contact to the client via XML:
<?xml version="1.0" standalone="yes"?>
<contact>
<reptype>update</reptype>
<domain>bG9jYXRpb24=</domain>
<aor>MDE4OTA5MDAy</aor>
<c>c2lwOjAxODkwOTAwMkA4My42NS40MC44Nzo1MDYwO3VzZXI9cGhvbmU7dHJhbnNwb3J0PXVkcA==</c>
<expires>1106312247</expires>
<q>-1</q>
<callid>MTkzNDY0MjcxN0A4My42NS40MC44Nw==</callid>
<cseq>15</cseq>
<replicate>0</replicate>
<state>1</state>
<flags>0</flags>
<user_agent>Q2lzY28gQVRBIDE4NiAgdjMuMi4wIGF0YXNpcCAoMDQxMTExQSk=</user_agent>
</contact>
Note that strings except reptype are base64 encoded.
The structure of the message will maybe change alot when we've defined
the details (which protocol, which messages etc), the current module
version is just a proof of concept, how contacts can be passed out of
the SER. So please continue contributing ideas ;o)
Btw, for serializing the ucontact_t structure to XML I use the structs
mechanism of libpdel (http://www.dellroad.org/pdel/index).
The external client (most of it has still to be implemented) has a list
of peers where this message has to be send to. If sending fails, it will
be put in a queue, and a timer triggers a retransmission.
Clients also listen for such replication messages from other peers and
write them to the SER fifo (or maybe directly via the module, don't know
yet ;o)
The external client can also be reused for provisioning, because you
just have to build the XML string in your web application and send it
via UNIX socket to the client like the SER module does.
Btw, as you can see: My time scope is ASAP ;o)
Andy