Hello,
it became a trend to add anchors to each header used by some module to sip_msg structure. While the average is 15 headers per SIP message (some without anchors in the sip_msg), sip_msg has over 35.
Many of these are used only once, e.g., presence related headers are used by router as endpoint, not as a proxy. Intended to endpoint are subject, supported, unsupported, and perhaps others... Keeping them and cloning in TM when proxying makes no sense. They are not used for routing.
I think would be good to replace some anchors or at least for future the addition of anchors with functions like:
get_hdr_xyz(sip_msg) - that will take care of parsing and return the right hdr_field structure.
On another hand I propose to add sortcut to body (start and length) - in this case if there is a correction done by the parser, will be in effect everywhere. Looking now in the code, there are functions that extract body in different ways, some correcting the length by skipping \r, \n at the end.
Cheers, Daniel
On Mar 30, 2009 at 23:21, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
it became a trend to add anchors to each header used by some module to sip_msg structure. While the average is 15 headers per SIP message (some without anchors in the sip_msg), sip_msg has over 35.
Many of these are used only once, e.g., presence related headers are used by router as endpoint, not as a proxy. Intended to endpoint are subject, supported, unsupported, and perhaps others... Keeping them and cloning in TM when proxying makes no sense. They are not used for routing.
I think would be good to replace some anchors or at least for future the addition of anchors with functions like:
get_hdr_xyz(sip_msg) - that will take care of parsing and return the right hdr_field structure.
I fully agree. I tried this once before, but hit some opposition :-)
The problem with lots of anchors is that each one uses 8 bytes on a 64-bit system and they add up (clone in tm a.s.o.). I would keep anchors only for the headers that are use a lot and that are used more then once per message processing cycle (e.g. if Foo is used only once by one module, it shouldn't get an anchor/shortcut).
On another hand I propose to add sortcut to body (start and length) - in this case if there is a correction done by the parser, will be in effect everywhere. Looking now in the code, there are functions that extract body in different ways, some correcting the length by skipping \r, \n at the end.
Why isn't get_body() enough? The message end is always at msg->buf+msg->len (but we can write a function or extend get_body() to return the len too).
Andrei
On 03/31/2009 12:38 PM, Andrei Pelinescu-Onciul wrote:
On Mar 30, 2009 at 23:21, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
it became a trend to add anchors to each header used by some module to sip_msg structure. While the average is 15 headers per SIP message (some without anchors in the sip_msg), sip_msg has over 35.
Many of these are used only once, e.g., presence related headers are used by router as endpoint, not as a proxy. Intended to endpoint are subject, supported, unsupported, and perhaps others... Keeping them and cloning in TM when proxying makes no sense. They are not used for routing.
I think would be good to replace some anchors or at least for future the addition of anchors with functions like:
get_hdr_xyz(sip_msg) - that will take care of parsing and return the right hdr_field structure.
I fully agree. I tried this once before, but hit some opposition :-)
ok :-) ... this time we have to advocate better.
The problem with lots of anchors is that each one uses 8 bytes on a 64-bit system and they add up (clone in tm a.s.o.).
the part with tm cloning is almost always a problem - people forget to add it to tm... maybe in the future we will find something more automatic, however not a subject for now.
I would keep anchors only for the headers that are use a lot and that are used more then once per message processing cycle (e.g. if Foo is used only once by one module, it shouldn't get an anchor/shortcut).
On another hand I propose to add sortcut to body (start and length) - in this case if there is a correction done by the parser, will be in effect everywhere. Looking now in the code, there are functions that extract body in different ways, some correcting the length by skipping \r, \n at the end.
Why isn't get_body() enough? The message end is always at msg->buf+msg->len (but we can write a function or extend get_body() to return the len too).
Yes, that shortcut can be get_body_len(...) or extend get_body(). I want single simple way to get them across code, instead of using some expression based on other fields.
Cheers, Daniel
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla