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