You are here: start » devel » xavp

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
devel:xavp [2009/05/27 21:55]
miconda 		devel:xavp [2009/07/28 13:09] (current)
82.113.121.84
Line 3: Line 3:
 <code> <code>
 Proposal and prototype implementation by: Proposal and prototype implementation by:
-   Daniel-Constantin Mierla <miconda [at] gmail (dot) com+   Daniel-Constantin Mierla <miconda [at] gmail (dot) com> 
 + 
 +CODE IN GIT REPOSITORY BRANCH: daniel/xavp 
 </code> </code>
  
 ===== Purpose ===== ===== Purpose =====
  
 +It is not a replacement for current AVP implementation, but a new feature (a new data structure available in code and config, similar to pseudo-variable like: sahred variable $shv(...), hash table variable $sht(...), private variable $var(...)). Developers and script writers can decide which one to use: AVP or XAVP.
 +
 +Primary goals:
   * ability to store more value types, not only integer and string   * ability to store more value types, not only integer and string
   * simplify addressing by using only string name for attributes   * simplify addressing by using only string name for attributes
   * possibility to optimise the search by creating lists of xavp lists   * possibility to optimise the search by creating lists of xavp lists
   * availability in config file for xavp with string or integer value (expression interpreter supports only these values) via PV module   * availability in config file for xavp with string or integer value (expression interpreter supports only these values) via PV module
 +  * availability in stateful processing, during the lifetime of transaction
  
 ===== Internal design ===== ===== Internal design =====
Line 77: Line 84:
  
   * **p** - pointer to your data - the data must be also allocated in shared memory   * **p** - pointer to your data - the data must be also allocated in shared memory
-  * *pfree** - function to free the data - it takes two functions as parameter - void pointer to data and a free function. The free function is provided by the core API, because depending on usage case it might be **shm_free()** or **shm_free_unsafe()**+  * **pfree** - function to free the data - it takes two functions as parameter - void pointer to data and a free function. The free function is provided by the core API, because depending on usage case it might be **shm_free()** or **shm_free_unsafe()**
  
 Example of usage (c-like pseudo-code): Example of usage (c-like pseudo-code):
Line 117: Line 124:
  
 NOTE: this avp printed to xlog will return a string: <<data:value of the pointer to data>> (e.g., <<data:0x973937393>>), good for debug purposes. NOTE: this avp printed to xlog will return a string: <<data:value of the pointer to data>> (e.g., <<data:0x973937393>>), good for debug purposes.
 +
 +This type of value is intended for internal usage, one of the modules that needs it immediately being **dialog**.
  
 === XAVP data value === === XAVP data value ===
Line 173: Line 182:
 When getting the value, no index or [0] point to same xavp - first one with respective name. When getting the value, no index or [0] point to same xavp - first one with respective name.
  
 +===== Benefits =====
 +
 +  * **grouping of value based on purpose**
 +    * for example, avps for serial forking:
 +
 +<code c>
 +$xavp(sf=>uri)="sip:10.10.10.10";
 +$xavp(sf[0]=>fr_timer)=10;
 +$xavp(sf[0]=>fr_inv_timer)=15;
 +$xavp(sf[0]=>headers)="X-CustomerID: 1234\r\n";
 +
 +$xavp(sf=>uri)="sip:10.10.10.11";
 +$xavp(sf[0]=>fr_timer)=20;
 +$xavp(sf[0]=>fr_inv_timer)=35;
 +
 +$xavp(sf=>uri)="sip:10.10.10.12";
 +$xavp(sf[0]=>fr_timer)=10;
 +$xavp(sf[0]=>fr_inv_timer)=15;
 +$xavp(sf[0]=>headers)="X-CustomerID: pw45\r\n";
 +
 +</code>
 +
 +For second destination, there is no extra header to be added. With current avp model, a dummy value must be set, otherwise the value from third destination will be used.
 +
 +  * **faster lookup**
 +     * with current avp, getting to last avp (as in above example) would require 11 steps in iteration. With xavp it takes 7 steps. When dealing with lot of avps, the improvement is more significant if the grouping is used.
 +     * from inside the code, the improvement is more visible, as the reference to inner xavp list can be kept at first lookup.
 +
 +  * **further improvements to speed and flexibility by storing generic data structures**
 +    * example: serial forking function can build now the info in a shared memory structure
 +
 +  * **less exposure the name conflicts by grouping**
 +    * modules can group their internal AVPs under a xavp, so other xavps with same name in global list won't affect the module functionality. Say dispatcher groups its avps under "dispatcher". Inside that list it can have xavp with names: dst, grp, cnt. In the global list or other sublists can be other avps with name 'dst', without any interference.
 +
 +  * **reduce number of parameters for some modules**
 +    * a module can reserve now only one name for xavp in default list. Inner xavp can have predefined names, without the risk for overlapping with other modules or config
 +    * **dispatcher** module can reserve xavp name "dispatcher" via modparam, while the names for AVPs dst, cnt, grp can be predefined and documented in readme.
 +
 +===== Use cases =====
 +
 +Couple of use cases I have in mind now:
 +
 +  * **acc** module for multi-leg accounting - grouping will improve speed and remove the wrong behaviour when a value is not set in one leg - null is set for the right leg, not for the last one.
 +  * **dispatcher** module - grouping
 +  * **dialog** module - store using generic data structure the dailog context pointer (get rid of current hack that adds a fake callback structure)
 +  * serial forking functions
 +  * possible in **lcr** or **carrierroute**
 +  * possible in **utils**, to store each line of http response in a grouped xavp list.
 +
 +===== Observations =====
 +
 +  * it is not a replacement to existing AVPs, but an addition, a new class of pseudo-variables

Trace:

Navigation

Wiki

Other

QR Code
QR Code devel:xavp (generated for current page)