#184 Load Dialogs in First child rather than in mod_init

ver 1.3.x
open
nobody
modules (140)
5
2008-09-19
2008-09-19
Carsten Bock
No

Hi,

attached the patch to load the dialogs in the first child rather than in during module initialization.
Actually i wanted to commit this to the souce tree, but due to Klaus' comment regarding new dialogs during loading, i've changed the dialog loading a little bit.
In order to be safe while loading the dialogs, the new version will re-enumerate the dialogs in the hash-table (dlg->h_id).
With my previous commit to the dialog-module (fallback to SIP-Element-matchings) this is safe, since the dialog-matching will fallback to SIP-Element-Matching and it is safe to load dialogs while new dialogs are created. However, i believe this is not the cleanest method; but however it works properly.
What do you think?
Attached patch is against OpenSER (Kamailio) 1.3.

Kind regards,
Carsten

Discussion

  • Ovidiu Sas
    Ovidiu Sas
    2008-09-24

    > In order to be safe while loading the dialogs, the new version will
    > re-enumerate the dialogs in the hash-table (dlg->h_id).
    What is unsafe in the existing version?

    If the dialogs are loaded in the first child, then we might be ready to receive SIP messages for dialogs that are not loaded. This may lead to races: a BYE is received for a dialog that is not loaded, we handle the BYE and then later on the dialog is loaded. As a result we end up with an orphaned dialog. Please correct me if I'm wrong.

    Regards,
    Ovidiu Sas

     
  • The actual implementation is exposed to lose BYEs, new calls and registrations while the dialogs are loaded. No SIP processing is happening.

    Even the dialog is loaded and a BYE comes for it, if loading takes more than retransmission, you end up with an orphan dialog as well.

    To get same behavior, the BYE (other requests) should be discarded by openser if it looks like belonging to a dialog and loading still happens.

     
  • Ovidiu Sas
    Ovidiu Sas
    2008-09-24

    > To get same behavior, the BYE (other requests) should be discarded by
    > openser if it looks like belonging to a dialog and loading still happens.

    This is the similar behavior today: while loading the dialogs, all the requests are discarded.
    In the new architecture, the advantage would be that new dialogs can be created while old dialogs are loaded ...

    I'm using the dialog module without db support and with dlg_match_mode set to 2. This is handled ok by most SIP UA (even broken ones that don't properly support rr params). If we load the dialogs in the newly proposed mode, there is an overhead for chacking the did, validate the did and then eventually fallback to SIP dialog element matching. Instead of supporting this many modes of dialog matching, why not focus on the proper SIP dialog element matching and discard the other matching methods. This will make the code cleaner and easier to maintain. Thoughts?

     
  • Carsten Bock
    Carsten Bock
    2008-09-24

    > If we load the dialogs in the newly proposed
    > mode, there is an overhead for chacking the did, validate the did and then
    > eventually fallback to SIP dialog element matching.

    If you have set dlg_match_mode = 2, there should be no difference for you. The dialog module will still only try to find the dialog based on the SIP-Elements only and ignore the did.
    I am convinced, that searching based on did is much faster than searching based on SIP-elements. I haven't actually measured it, has anyone?

    Carsten

     
  • Ovidiu Sas
    Ovidiu Sas
    2008-09-24

    I'm doing traffic at 150cps with dialog matching mode set to 2 and the load is minimum, 95%cpu idle (quad core @3.20GHz). I don't think that the dialog matching mode makes a big difference in terms of CPU load.

     
  • Hi Carsten,

    what is the state of this patch? I just tested it, i don't apply anymore against trunk or branch 1.5. Do've any plans to update it to the current trunk?

    Henning