[Serusers] header matching

[Andrei Pelinescu-Onciul]

On Sep 19, 2003 at 00:35, Felix Schmid <felix at belugalounge.net> wrote:
> Andrei,
> 
> forgive my ignorance - but you have lately explained the same thing to
> me.
> Can you explain to me where the performance win is actually gained?

[cc'ed to serusers]

If we would directly modify the message:
 - we might need to realloc if the msg. size increases
 (if I add 5 headers in different points this would mean 5 reallocs +
 memcpys)
 - the message would have to be re-parsed on each addition/deletion
  (to avoid extra alloc+mem copy operations we keep the offsets to the headers 
  in the original message)

In general the most time-consuming part of the message processing is the
message parsing.

Also from my point of view is much saner to always "work" on the
original (non-modified) message.


> Isn't almost every message forwarded/relayed?

Yes.

> What about retransmits
> within transactions (I suppose ser attempts to retransmit t_relay'ed
> messages)?

On first transmit attempt the transmitted message is generated (= orig.
message + apply lumps/diffs). After that a copy of it it's stored for
retransmissions (if you use the statefull part: tm+ t_relay*).

Andrei
> 
> On Thu, 2003-09-18 at 12:48, Andrei Pelinescu-Onciul wrote:
> > > however, this does not seem to work. is the rpid really added to the
> > > message at when requested or actually later (at transmit) ?
> > 
> > At transmit. Amost all the stuff that gets added will show up only at
> > transmit time (you will see the original message, one exception is uri
> > processing -- you'll always see the modified uri).
> > The ideea is to keep the original message and a set of diffs to it
> > (struct lump). This "diffs" will be applied only on transmit. This will
> > speed things up quite a bit.
> > 
> > 
> > Andrei
> > 
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> -- 
> PGP-Key: http://belugalounge.net/~felix/Felix%20Schmid.asc
>