[OpenSIPS-Devel] SF.net SVN: opensips:[8105] trunk/modules/usrloc

[Bogdan-Andrei Iancu]

Hi Aron,

On 06/30/2011 10:40 PM, Aron Rosenberg wrote:
> Bogdan and Stan,
>
> On Thu, Jun 30, 2011 at 11:14 AM, Bogdan-Andrei Iancu 
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
>     Hi Stan,
>
>
>     On 06/30/2011 08:48 PM, Stanisław Pitucha wrote:
>
>         On 30 June 2011 17:25, Bogdan-Andrei Iancu<bogdan at opensips.org
>         <mailto:bogdan at opensips.org>>  wrote:
>
>             Revision: 8105
>             http://opensips.svn.sourceforge.net/opensips/?rev=8105&view=rev
>             <http://opensips.svn.sourceforge.net/opensips/?rev=8105&view=rev>
>             Author:   bogdan_iancu
>             Date:     2011-06-30 16:25:18 +0000 (Thu, 30 Jun 2011)
>
>             Log Message:
>             -----------
>             - fixed race between UPDATE and DELETE when using DB_ONLY
>             mode (one processe can update a record, while timer proc
>             tries to delete it). The result is loosing contacts from
>             database. The fix is to use REPLACE (if available on DB
>             level) instead of UPDATE (as records may be missing).
>              Based on an original idea from patch #2969454; Credits go
>             to Stanislaw Pitucha
>
>         I think a bit too much stuff was stripped. Now the old db
>         schema is
>         used without any control from the user.
>         That means there's no unique key to generate the conflict
>         (update/replace happens only on key collision) on insert
>
>     Thanks for reminding me on that - I almost forgot to update the DB
>     schema and to add the unique key constraint as you mentioned  -
>     just did that
>
>
>          and no way to
>         turn off the "atomic" updates from the config if you want the old
>         schema... Unless it's properly documented in the manual it
>         might cause
>         some really bizarre situations for people using DB_ONLY.
>
>     What kind of side effects are you referring at ? My idea was to
>     try to automatically fix the problem (when DB_ONLY is used),
>     transparent for the user. Of course, it is not a big deal to add
>     the config switch for that, but I don't see why you should disable
>     it and run a buggy code :D.
>
>     Thanks and regards,
>     Bogdan
>
>
>     -- 
>
> One major issue with enforcing a unique index on username,contact is 
> that if a client comes in and is using a Path: header, the contact 
> address is irrelevant and not "fixed up" so two accounts from behind 
> NAT's both on the 192.168.1.x range will have conflicts resulting in 
> one endpoint being silently dropped. I believe this is also a problem 
> with the internal hash table too.
Partially you are right :) - the internal hash is not affected as it is 
using the callid also as key (see the match mode in the usrloc module). 
But about the DB, you are right - in NATed cases, contacts may overlap.
As fix I suggest adding the callid field in the "unique" key also. This 
should cover all the cases (when received or path is used).

Thanks and regards,
Bogdan




-- 
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20110701/3d73c33a/attachment.htm>