On Sep 19, 2003 at 00:35, Felix Schmid <felix(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers --
PGP-Key:
http://belugalounge.net/~felix/Felix%20Schmid.asc