Indeed, it is even more complex :-)
So, depending on the Event type - e.g. presence allows sending NOTIFY without waiting for the response, but xcap-diff does not allow it - we would have to queue notifications and then have a dedicated NOTIFYer who performs the notifications. I do not think that a single NOTIFYer can be blocked, as UDP is always non-blocking and TCP is now non-blocking too.
regards Klaus
On 27.03.2012 16:43, Anca Vamanu wrote:
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=ae86ca36...
Author: Anca Vamanuanca.vamanu@1and1.ro Committer: Anca Vamanuanca.vamanu@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=ae86...
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev