27 Mar
2012
27 Mar
'12
5:43 p.m.
Hi Klaus,
I thought about these race conditions also.
The problem is a bit more complicated because with UDP actually we can
not assure that the requests will be received in the same order by the
destination even if they are send by the same process. As an example, we
have the problem with the Notify that is received before 200OK for
Subscribe in some cases even if they are generated by the same process.
So I don't know if there is much point in implementing a more rigorous
synchronization considering this..
Of course for TCP it would make more sense and the 100% sure solution is
indeed the second one that you proposed - having a specialized process
to send out the Notifies. But this is the most complicated, as actually
we might need a pool of processes not to get blocked because one
destination is unreachable for example. And then we would need the
divide the Notifies per destination to actually ensure that one process
receives all the Notifies for a certain destination.
The first solution that you propose is not that difficult to implement -
to have an array of locks and take the corresponding lock when updating
a certain dialog ( hash on a callid for example). And do an update
immediatelly after search and both under the lock. This would not insure
a 100% synchronization but better then now.
Regards,
Anca
On 03/27/2012 02:46 PM, Klaus Darilion wrote:
Hi Anca!
I just wondered if race conditions are handled properly (DB-only mode)
E.g. there are 2 PUBLISH for a certain presentity (or a PUBLISH and
reSUBSCRIBE) received almost at the same time. Processing of these
PUBLISH can happen in different processes (or servers), thus when
generating the NOTIFY I think it can happen that both processes try to
UPDATE the cseq and e.g. use the wrong cseq when sending the NOTIFYs.
Reading the cseq and increasing the cseq should happen in a transaction
with a row lock.
Another approach would be to have a dedicated NOTIFYer process which
takes care of sending NOTIFYs. On reSUBSCRIBE or PUBLISH a presentity
gets marked for updates (e.g. in a separate table) and the NOTIFYer
polls this table and sends the NOTIFYs in proper order.
What do you think about that?
regards
Klaus
On 15.02.2012 13:45, Anca Vamanu wrote:
Module: sip-router
Branch: master
Commit: ae86ca3611398ce365ac4a1776ff0c7e95476bbe
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=ae86ca3…
Author: Anca Vamanu<anca.vamanu(a)1and1.ro>
Committer: Anca Vamanu<anca.vamanu(a)1and1.ro>
Date: Wed Feb 15 13:39:55 2012 +0200
modules_k/presence Fixed DB Storage Modes
- removed db_mode and fallback2db parameters and added two new
parameters: subs_db_mode and publ_cache
- fixed and extended the storage modes for subscriptions: Memory Only,
Write Through, Write Back, DB Only
- publ_cache parameter offers the possibility to disable publish cache
- some other fixes:
- delete subscription only for 481 or 408 reply for Notify
- call child_init also for main process (no shutdown DB flush was
being performed)
---
modules_k/presence/README | 190 ++++++-----
modules_k/presence/bind_presence.c | 4 +-
modules_k/presence/bind_presence.h | 4 +-
modules_k/presence/doc/presence_admin.xml | 127 +++++---
modules_k/presence/doc/presence_devel.xml | 2 +-
modules_k/presence/event_list.c | 2 +-
modules_k/presence/event_list.h | 2 +-
modules_k/presence/hash.c | 25 +--
modules_k/presence/hash.h | 2 +-
modules_k/presence/notify.c | 253 ++++++---------
modules_k/presence/notify.h | 2 +-
modules_k/presence/presence.c | 108 +++----
modules_k/presence/presence.h | 19 +-
modules_k/presence/presentity.c | 30 +--
modules_k/presence/presentity.h | 2 +-
modules_k/presence/publish.c | 52 ++--
modules_k/presence/publish.h | 2 +-
modules_k/presence/subscribe.c | 495 +++++++++++++++++++----------
modules_k/presence/subscribe.h | 7 +-
modules_k/presence/utils_func.c | 2 +-
modules_k/presence/utils_func.h | 2 +-
modules_k/pua/hash.h | 1 +
22 files changed, 736 insertions(+), 597 deletions(-)
Diff:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=ae8…
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev