[Users] Serial forking

Klaus Darilion klaus.mailinglists at pernau.at
Thu Dec 1 14:20:33 CET 2005


search the mailinglist archive (openser + ser)

klaus

Matteo Piazza wrote:
> Hi,
> yuo can me send an example of a LCR DAtabase compiled
> Thank's
> 
> | prefix | from_uri | grp_id | pryority |
> -----------------------------------------
> |    ?   |    ?     |    ?   |    ?     |
> |    ?   |    ?     |    ?   |    ?     |
> 
> 
> 
> Bogdan-Andrei Iancu wrote:
> 
>> Hi Tim,
>>
>>
>> Tim Klein wrote:
>>
>>> Bogdan said:
>>>
>>>> I just committed serial proper forking support into core - it was 
>>>> migrated from LCR module. I mean proper, since it has q value 
>>>> support and it can be used by any module without any inter-module 
>>>> dependencies.
>>>>
>>>> The idea behind was to allow to all module that performs parallel 
>>>> forking to do also serial forking - exec, enum, registrar, etc.
>>>
>>>
>>>
>>>
>>> That's good news!  Thank you!
>>>
>>> But I have some questions to help me understand the new functions. 
>>> Please see below...
>>>
>>>> There are two new script functions :
>>>>     *serialize_branches(n)* : it inherits the functionality of 
>>>> load_contacts() from LCR; gets all parallel branches and convert 
>>>> them into AVPs for serial forking; numerical parameter 'n' says if 
>>>> any previous AVP should be removed (if non-0) or not (if 0). Returns 
>>>> true is no error (even if no serialization happened).
>>>>     *next_branches()* : it inherits the functionality of 
>>>> next_contacts() from LCR; get (based on q value) the next contact(s) 
>>>> to be used in  sequential forking. Returns true only if a new 
>>>> contact was got to be used.
>>>>
>>>> The AVP containing the branches is accessible only via alias - its 
>>>> ID is not configurable or visible; the alias (automatically exported 
>>>> by core) is "serial_branch" - it is visible from any module that 
>>>> uses the avp core aliasing system.
>>>
>>>
>>>
>>>
>>> My questions:
>>>
>>> Let's say there are 4 contacts registered.  Two of the contacts ("A" 
>>> and "B") have q value of 1.0.  The other two contacts ("C" and "D") 
>>> have q value of 0.5.
>>>
>>> Using the following routing script, which contacts will be tried in 
>>> the main route block, and which will be tried in the failure_route 
>>> block?
>>>
>> according to RFC and Q interpretation, you will get in request route 
>> the C and D contacts (as they have the lower q (higher priority) and 
>> their q is equal. In failure route you get A and B (as they have the 
>> same q).
>>
>> regards,
>> bogdan
>>
>>>       modparam("registrar", "append_branches", 1)
>>>       .....
>>>       {
>>>          .....
>>>          lookup("location");
>>>          serialize_branches(1);
>>>          t_on_failure("1");
>>>          t_relay();
>>>       }
>>>
>>>       failure_route[1] {
>>>          if (next_branches()) {
>>>              t_relay();
>>>          }
>>>       }
>>>
>>>
>>> Thank you!
>>>
>>> Tim
>>>
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
> 
> 





More information about the sr-users mailing list