[reSIProcate] Distributing the TransactionState class across mutliple stacks

[Andrew Wood]

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 at resiprocate.org
List Archive: http://list.resiprocate.org/archive/resiprocate-users/