[reSIProcate] Fifos, TuSelectors, shutdown & DumProcessHandler

[derek]

At the last working group we introduced the idea of a TuSelector which
effectively replaces the TuFifo of the SipStack.  We are now seeing issues
w/ shutdown, statistics, etc.  Here is a design proposal to clean up our use
of tu's which should also help w/ different threading/processing models.  

 

-= Overview =-

 

The core of the idea is to not have component own the fifo which is
effectively the next hop; the SipStack currently owns the TuFifo, which
needs to be polled w/ receive or receiveAny.  TransactionUser is closer to
the new model; it own it's fifo, which are written to by the TuFifo but are
owned by the TransactionUser.

 

In the new approach, the fifo would be abstracted as a 3 method interface
which represents the next step in the pipeline:

 

class HalfPipe

{

   virtual void post(Message* msg, DepthUsage usage); //may want to clean up
depth usage/have 2 posts

   virtual int size() const;

   virtual bool wouldAccept(DepthUsage usage) const;

};

 

This would be passed to the SipStack as a constructor parameter, and replace
mTuFifo. TuSelector would be a subclass of HalfPipe; TuSelector relies on
information about which tu sent request/posted a message; this could be
replaced w/ an opaque piece of userdata which can be used to match
requests/responses/failure message back to the originating Tu.  

 

-= Shutdown & Statistics(the app vs the Tu) =-

 

With the introduction of the TuSelector, there are new messages that are
only of interest to the app(Tu shutdown, stats) which need to be consumed.
Right now these go directly to SipStack::mTuFifo.  In the new approach,
TuSelector would inherit from Halfpipe, but would also take a Halfpipe as a
cons. parameter which represents the apps fifo; TuSelector(HalfPipe&
applicationFifo).  Any message that isn't matched to a fifo would go there,
currently shutdown + statistics.

 

Once all TransactionUsers have been shutdown(the TuSelector could provide a
specific method for this), the app can shutdown the stack.  The app could
simply end any stackthread/stop calling process, but it might want to wait
for all retransmissions to finish or each message to be transmitted at least
once.  The SipStack already shutdown routine like this which would be a
basis for this. 

 

-= Threading/Processing Models(DumProcessHandler) =-

 

With the introduction of external transports that are not select based,
there was a requirement to get the SipStack/Dum cycles when external events
occurred.  DumProcessHandler is a rather messy realization of this
requirement. Here is the new approach:

 

SipStack would still have a AsyncProcessHandler, but this will not interact
with Tu(ie dum) processing.  Tu's needing to process incoming events without
polling would do this by subclassing the specific TransactionUser or
TuSelector to give cycles to the TransactionUser. Applications that do not
wish to poll for shutdown/statistics messages could write a HalfPipe that
acts as a synchronous demuxer of events.

 

-= Porting existing applications =-

 

Applications that are built directly on top of the SipStack would just have
to provide a TimeLimitFifo<Message> as a SipStack constructor, and do the
equivalent of receive/receiveAny directly against the fifo in their
build/select/process loop. 

 

Applications built on top of DUM will not have to do anything different as
dum will be ported to this new approach.

 

 

Comments/Suggestions/Requirments?

 

--Derek

CONFIDENTIALITY NOTICE

This email and any files transmitted with it contains proprietary
information and, unless expressly stated otherwise, all contents and
attachments are confidential. This email is intended for the addressee(s)
only and access by anyone else is unauthorized. If you are not an addressee,
any disclosure, distribution, printing or copying of the contents of this
email or its attachments, or any action taken in reliance on it, is
unauthorized and may be unlawful. If you are not an addressee, please inform
the sender immediately and then delete this email and any copies of it.
Thank you for your co-operation.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20050415/c5a856c0/attachment.htm>