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
Yxa-devel@lists.su.se
https://lists.su.se/mailman/listinfo/yxa-devel

Reply via email to