[reSIProcate] Distributing the TransactionState class across mutliple stacks
- From: Andrew Wood <ajwood@xxxxxxx>
- Date: Tue, 14 Oct 2008 13:22:18 +0100
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/