Re: [reSIProcate-users] Distributing the TransactionState class across mutliple stacks
The DNS complications of what you are trying to accomplish are huge.
Also not sure that you need any of this to achieve your goal. Proxies
are not session stateful so any new transaction can go to a different
stack already.
Sent from my iPhone
On Oct 14, 2008, at 5:22, Andrew Wood <ajwood@xxxxxxx> wrote:
Im looking at a way of making instances of TransactionState visible
to mutliple stacks running on separate machines so that if one
machine / stack fails part way through a transaction the rest of the
transaction can be seamlessly handled by another. It will also
provide load balancing by allowing any message to be handled by any
stack instance.
Having spent a few days looking through the code and mapping out a
class diagram and tracing the basic interactions between the classes
when handing a message I'd like to share my ideas and see what you
think, is it sound and have I overlooked anything?
The idea is to alter the TransactionMap class so that instead of
storing TransactionState objects its local collection it stores them
in a relational database to which all stacks have access. I would
use Sun's Data Access Object 'blueprint' to persist & restore
instances of TransactionState to the DB, so there would be a
TransactionStateDAO object which is responsible for reading &
writing TransactionState objects to the DB, as requested to do so by
the modified TransactionMap.
Obviously at least initally whilst I prove the basic idea I want to
keep thing as simple as possible, so objects referenced by
TransactionState pose a slight problem as they would need to be
persisted as well. To overcome this for the time being Im prooposing
getting the TransactionStateDAO to do the following with the
following variables linked objects:
mController: DAO doesnt write anything to DB for this when
persisting, on restore, it sets it to the local stacks
TransactionController.
msgToRestransmit: serialise as a string in the DB and create a new
SipMessage object from the string when restoring
mDNSResult: unsure about this, havent worked out its purpose yet.
Perhaps you could enlighten me?
mTarget & mResponseTarget: store IP addr & port in DB as simple
strings & ints and create new object from those when restoring
mOriginalContact & mOriginalVia & mID: store as strings and create
new objs from those strings when restoring
mTransactionUser: doesnt write anything to DB for this when
persisting, on restore it sets it to the local stacks TU
The ultimate aim would be that ANY SIP message for a call could be
received by ANY stack instance, as would be useful when building
proxy servers.
Any thoughts welcome.
Regards
Andrew
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/