Re: [reSIProcate] The Million User Dilemma
Hi Francis,
Repro to my knowledge, suffers problems similar to the stack and dum.
We will make the biggest improvements in repro first by fixing those
areas. Then we can build out new database backends for repro possibly
using some sort of peer to peer network for managing registration state.
Likewise, hash based concurrency like I've done with the transaction
layer can be applied to repro to make it more parallel.
As for replicating more information, Byron has pointed me in the
direction of GRUU and SIP RELOAD. These allow users to register to
multiple proxies at the same time with a globally unique identifier as
the contact. I'm sure this will take a bit of work to add, but I think
it is th future of what we need to do to make this support the numbers
of users we're talking about.
Dan
On 02/01/2011 07:21 AM, Francis Joanis wrote:
> Hi Dan,
>
> I realized our discussion mostly focused on the performance/scalability
> improvements that could be done in resip/dum but what about repro itself?
>
> I must say I have never used it but going back to your original post you
> mention having a large network of them (kinda like a "cluster" I
> guess). Since it is a proxy, it might need to cache and replicate data
> like user registration contacts across its peers.
>
> For large-scale data replication it might make sense to use a different
> data store like Basho Riak or CouchDB (I understand those are built for
> large-scale deployment - it's probably no coincidence that those two are
> built using Erlang ;) ).
>
> Would you foresee the need to replicate more than that type of
> information? What about SIP-specific stuff like dialogs and transactions
> (stateful proxy, maybe)? That way, another proxy could takeover in the
> middle of a transaction... quite ambitious goal :).
>
> The alternative could be to leverage SIP's "forgiveness". For example,
> if a transaction fails because of a proxy failure/..., then it would be
> up to the upstream UA to retry it.
>
> It would be very interesting if resip/dum could have the data parts of
> its transactions and dialogs orthogonal to its operational parts
> (implementations, algorithms). For example, if we could seamlessly store
> the dialog information into a replicated data store so that multiple DUM
> instances can use them.
>
> Cheers,
> Francis