28 Jul
2009
28 Jul
'09
2:31 p.m.
Hello,
some time ago I created a new branch in GIT named 'daniel/xavp' that
includes code for a new pseudo-variable class 'xavp' - name being a
shortcut to 'extended attribute value pair'. I collected some design
details in wiki:
http://sip-router.org/wiki/devel/xavp
It is not a replacement for current AVP api implementation, although in
the future can replace it. In the past we had couple of discussions
about the limitations of avps which I tried to overcome. Here are some
highlights of xavp design:
- string names only - various tests showed that having the complex
addressing scheme with integer id and string name does not pay off
performance gains. XAVP computes and integer id for each name that is
used to speed up comparison
- possibility to store more data types - AVP allow string and integer
data types. More can be handled by XAVP, including a generic data type
where you can build your own structure and store it in the list. This is
good for example to store custom structures for transaction lifetine --
right now dialog module needs to store reference to dialog structure.
Optimizations can be done for any case of serial forking -- uri, dst
uri, q, etc can be stored in a structure without a need to parse and
build it from an encoded value stored in one or many avps
- possibility to group XAVPs inside another XAVP - practically is
building lists of XAVPs. This should overcome issues with naming
conflicts between modules - e.g., dispatacher module can group its avps
in a list named "dispatacher", lcr module in a list named 'lcrl, then
there can be XAVP with name 'uri' in both lists, without the risk of
misusage. Another benefit would be reducing the number of parameters,
right now each module exports a parameter to set the name for each AVP,
with xavp there is need for one parameter to set the name of the list,
then inside that list the module is free to use predefined names without
the risk of overlapping.
- xavp having value integer or string can be used directly in config,
whether they are in a sublist or not
Check the wiki (link above) for more. Looking forward for comments,
suggestions and improvements.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* SIP Router Bootcamp
* Kamailio (OpenSER) and Asterisk Training
* Berlin, Germany, Sep 1-4, 2009
* http://www.asipto.com/index.php/sip-router-bootcamp/
28 Jul
28 Jul
2:51 p.m.
Daniel-Constantin Mierla wrote:
- possibility to store more data types - AVP allow string and integer
data types. More can be handled by XAVP, including a generic data type
where you can build your own structure and store it in the list. This is
good for example to store custom structures for transaction lifetine --
right now dialog module needs to store reference to dialog structure.
Optimizations can be done for any case of serial forking -- uri, dst
uri, q, etc can be stored in a structure without a need to parse and
build it from an encoded value stored in one or many avps
You could generalize this into only using the generic data value and
wrap the other types into these. This requires makeing these generic
data values in the script language somehow. For all this, you will need
a somewhat more elaborate interface to the type than a free function.
I suppose you could define a struct much like the module struct that
contains a bunch of pointers to various functions for various things. An
instance of this type then consists of a pair from the pointer to the
type struct (which incidentally is uniquely identifying the type and a
pointer into shared memory pointing to the value).
- possibility to group XAVPs inside another XAVP -
practically is
building lists of XAVPs.
If you wrap this into a generic type, you can have various types for
lists and maps and whatnot (although this should really do). There are
some questions around references vs. copies here, so this will probably
go off into reference counting and stuff.
Although, neatly enough, this can probably made in such a way that XAVPs
get auto-magically destroyed when their parent object (the transaction,
dialog, etc.) is being destroyed.
Regards,
Martin
29 Jul
29 Jul
12:35 p.m.
On 28.07.2009 13:51 Uhr, Martin Hoffmann wrote:
Daniel-Constantin Mierla wrote:
it is an option, but I wanted to have it simple for common data types in
the same time to allow dealing with more complex structures.
This can be implemented for generic data, so it adds kind of: fromStr
and toStr functions, making possible to set/get values from config.
- possibility to store more data types - AVP
allow string and integer
data types. More can be handled by XAVP, including a generic data type
where you can build your own structure and store it in the list. This is
good for example to store custom structures for transaction lifetine --
right now dialog module needs to store reference to dialog structure.
Optimizations can be done for any case of serial forking -- uri, dst
uri, q, etc can be stored in a structure without a need to parse and
build it from an encoded value stored in one or many avps
You could generalize this into only using the generic data value and
wrap the other types into these. This requires makeing these generic
data values in the script language somehow. For all this, you will need
a somewhat more elaborate interface to the type than a free function.
I suppose you could define a struct much like the
module struct that
contains a bunch of pointers to various functions for various things. An
instance of this type then consists of a pair from the pointer to the
type struct (which incidentally is uniquely identifying the type and a
pointer into shared memory pointing to the value).
with current implementation, this is a matter of what free function does
for generic data type. For the common types, free is done automatically,
being easier for developers.
- possibility to group XAVPs inside another XAVP
- practically is
building lists of XAVPs.
If you wrap this into a generic type, you can have various types for
lists and maps and whatnot (although this should really do). There are
some questions around references vs. copies here, so this will probably
go off into reference counting and stuff.
Although, neatly enough, this can probably made in
such a way that XAVPs
get auto-magically destroyed when their parent object (the transaction,
dialog, etc.) is being destroyed.
Now they are attached to transaction and auto-destroyed when the
transaction terminates -- same like with AVP list. The API allow to work
with custom xavp lists, therefore developer can attach new lists to
different contexts -- will need to extend the interface to config, as
the PV export is using the default list bound to sip message/transaction.
Thanks,
Daniel
--
Daniel-Constantin Mierla
* SIP Router Bootcamp
* Kamailio (OpenSER) and Asterisk Training
* Berlin, Germany, Sep 1-4, 2009
* http://www.asipto.com/index.php/sip-router-bootcamp/
12:52 p.m.
Daniel-Constantin Mierla wrote:
On 28.07.2009 13:51 Uhr, Martin Hoffmann wrote:
Agree. I was actually more thinking into the future and into a Grand
Unified Variable kind of thing. Not sure if this should be a service
provided by the core or some module. But should we agree that we want
such a thing then it might be better to work on that instead of building
an interims solution based on AVPs.
This is not to diminish your work in any way, I quite like the
possibilities especially with the option for lists. It just may safe you
same work that will eventually be superseded by something else.
Regards,
Martin
You could generalize this into only using the generic data value and
wrap the other types into these. This requires makeing these generic
data values in the script language somehow. For all this, you will need
a somewhat more elaborate interface to the type than a free function.
it is an option, but I wanted to have it simple for common data types in
the same time to allow dealing with more complex structures.
1:49 p.m.
On 29.07.2009 11:52 Uhr, Martin Hoffmann wrote:
Daniel-Constantin Mierla wrote:
the core has to provide at least the mechanisms to hook up to different
contexts (e.g., like now to sip message/transaction). The PV interface
implementation is done in pv module, so that is not bound to core at
all. Without pv module, xavp cannot be used from config.
To the other matter, I brought this to discussion to find the best
solution, therefore all is open. There is no memory penalty as the value
is a union, if one uses only the generic data it is not affected by the
existence of the other simple data types.
I am not a fan of over-engineering, trying to keep being practical, not
getting to something very complex due to nature of variables existing
now, in kamailio (at least) there are references inside the sip message,
to the proxy and OS environment, to shared and private memory, list of
values in share memory (avps), database query result, hash table (local
cache), memcached data (distributed cache). What is common to all these
is the interface to config file -- each exports set/get function to/from
int or str values.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* SIP Router Bootcamp
* Kamailio (OpenSER) and Asterisk Training
* Berlin, Germany, Sep 1-4, 2009
* http://www.asipto.com/index.php/sip-router-bootcamp/
On 28.07.2009 13:51 Uhr, Martin Hoffmann wrote:
Agree. I was actually more thinking into the future and into a Grand
Unified Variable kind of thing. Not sure if this should be a service
provided by the core or some module. But should we agree that we want
such a thing then it might be better to work on that instead of building
an interims solution based on AVPs.
This is not to diminish your work in any way, I quite like the
possibilities especially with the option for lists. It just may safe you
same work that will eventually be superseded by something else.
You could generalize this into only using the
generic data value and
wrap the other types into these. This requires makeing these generic
data values in the script language somehow. For all this, you will need
a somewhat more elaborate interface to the type than a free function.
it is an option, but I wanted to have it simple for common data types in
the same time to allow dealing with more complex structures.
5595
days inactive
5596
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Martin Hoffmann -
Martin Hoffmann