On Wed, 2009-11-25 at 16:58 -0500, Kaiduan Xie wrote: > Hi, all, > > I have two questions on the design of YXA.
I appreciate that someone takes the time to look that deep into the source code. Thanks! > 1. Client transaction and server transaction are implemented as > gen_server, why not choose gen_fsm? > Client and server transaction are all described as FSM in rfc3261, > gen_fsm woulld be a very good fit. No real reason I guess, you are welcome to try and re-implement them as gen_fsm to see if that actually works. I have a suspicion that although the transaction state is a fsm, not everything a client/server transaction process does fits into gen_fsm, but this is only a suspicion. The real reason might be as simple as me being more comfortable with gen_server module than gen_fsm. > 2. For each incoming SIP message, YXA spawns a process no matter if > the message is a part of transaction or not. > For the following typical proxy call flows, > > UAC Proxy UAS > > | INVITE-1 | | > |------------------>| | > | 100-2 | | > |<------------------| INVITE-3 | > | |------------------->| > | | 100-4 | > | |<-------------------| > | | 180-5 | > | |<-------------------| > | 180-6 | | > |<------------------| | > | | 200-7 | > | |<-------------------| > | 200-8 | | > |<------------------| | > | | | > | ACK-9 | | > |------------------>| | > | | ACK-10 | > | |------------------->| > > > Upon receiving Message 100-4, message 180-5, and message 200-7, YXA > creates a process, and then just passes the message to client and > server transaction. Does it? I don't have the time to actually look it up, but my recollection is that a "message handler" process is created _after_ the transaction layer has decided that it has no ongoing transaction to pass the request (ACK or resend)/response to. > Is it better to find if the message is part of client/server > transaction first, if yes then just passes the message to the > corresponding transaction without spawning a process? Perhaps. Not spawning a process means that some central process has to do a lot more processing, which will be sequential - read: become a bottleneck. Also, spawning in Erlang is really _really_ cheap. I bet that optimizing sipurl parsing will give you perhaps 10-20x more TPS (transactions per second) speed increase than optimizing away a spawn per request/response. As a matter of fact, I'm about to upgrade sipurl to use the new re module instead of the old regexp. From what I've understood, the re module is quite a bit faster. /Fredrik _______________________________________________ Yxa-devel mailing list [email protected] https://lists.su.se/mailman/listinfo/yxa-devel
