I actually also meant the hot-standby scenario. So all you had to do was
to change the totag generation to be identical on both sides? Still a
hack but it will work ;-)
Of course this hack only achieves HA, but does not improve scalability.
The new modes will allow multiple presence servers in active-active
setup, but moves the bottleneck to the DB. Maybe some caching can be
used depending on dispatching configuration of the load-balancer. I
guess I have to think some more about that.
regards
Klaus
On 20.02.2012 12:03, Anca Vamanu wrote:
Hi Klaus,
It's not quite the way you described it. In the scenario describe by me,
p2 was just a hot stand by, sending nothing outside while in backup
mode. In an active - active setup, it is a lot harder to achieve.
First, as Daniel suggested, send() is the best option to use when
replicating - forwarding the message as it was received.
Then, p2 should work in a synchronous way - generating the same tag and
Via branch as p1. With the Via branch it is easy to achieve with the
*syn_branch* global parameter. With the tag, some coding needs to be done.
P2 should not send anything out, it should be blocked at network layer,
or from inside the application. However it will have the impression it
had send out the Notifies, so it has to receive the replies for it. This
is why p1 must also replicate replies for Notifies.
Regards,
Anca
On 02/20/2012 12:43 PM, Klaus Darilion wrote:
Hi Anca, that sounds like an awful hack ;-)
Just to be sure that I really understand the hack - for example presence
server p1 and backup presence server p2.
p1 receives SUBSCRIBE: local handle_subscribe() and t_replicate() to p2
p1 sends back 200 OK and stores dialog.
p2 sends back 200 OK to p1, but using a different to-tag thus having
another dialog. Thus, NOTIFYs by p2 have a different Via branch-id and a
different from-tag. Thus, I wonder how failover to the backup-node
should work and how the backup node will accept a faked NOTIFY-response
if branch-param and from-tag are different ???
thanks
Klaus