[reSIProcate] RE: Alternative "async/external" Processing Model

Fri Apr 8 12:55:12 CDT 2005

I am planning to clean the cycle/threading abstraction up, but I need to
think about the design a bit. I'll be off network for a while but I should
have a design proposal for the list by the end of next week.

--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.

  _____  

From: Bellanger Julien [mailto:julien.bellanger at capgemini.com] 
Sent: Friday, April 08, 2005 7:04 AM
To: derek
Cc: resiprocate-devel at list.sipfoundry.org
Subject: Re: Alternative "async/external" Processing Model

If I well unterstood, the DumProcessHandler is usefull only in a
architecture based on DUM/Stack in the same thread

and Transport in separate threads ?

What I am searching for is a mean to have a Call Back called each time an
event is posted to the TUFifo when the Stack

and Transport run in different threads than the DUM application.

In this Call Back I could signalled a system event that will wake up my DUM
thread which is blocked on multiple event object.

Thus on wake up, the DUM thread know it must call procces() method to
process a new event in its Fifo.

Is it possible to do that with the TuSelector ?

It doesn't seem possible at that time, but if ever we add a virtual method
to TransactionUser class that is called

after each msg post in TUFifo, could it be solved my problem ?

I'm a newbie in using resiprocate, so perhaps I am missunderstood some
concept about the management of DUM 

event management, so just tell me. Thanks

Julien

----- Original Message ----- 

From: derek <mailto:derek at xten.com>  

To: 'Bellanger <mailto:jbellang at capgemini.fr>  Julien' 

Cc: resiprocate-devel at list.sipfoundry.org 

Sent: Thursday, April 07, 2005 5:33 PM

Subject: RE: Alternative "async/external" Processing Model

The DumProcessHandler doesn't poll the SipStack; no timers are sent when
there isn't outstanding work to be done.  It will be refactored wrt to
TuSelectors, but it was designed to fit DUM/resip into a certain set of
architectural constraints and was not designed to be threadsafe.

--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.

  _____  

From: Bellanger Julien [mailto:julien.bellanger at capgemini.com] 
Sent: Thursday, April 07, 2005 2:29 AM
To: derek
Cc: resiprocate-devel at list.sipfoundry.org
Subject: Alternative "async/external" Processing Model

Hi,

I have some questions about how to safely use the AsyncProcessHandler

which is passed to the DUM constructor.

In my anderstanting this handler is notified in these cases:

- when the transport Layer post a message to the Stack Fifo,

- when the Stack find a timer fired and post it to the Stack Fifo or TU
Fifo,

- when the Stack post an Event to the TU Fifo

So the AsyncProcessHandler is called when there is an event for the

Stack OR the DUM,

Is this means that the Stack and DUM should run in the same Thread 

when using the async processing model ?

In my advise, it could be interresting to have two type of
AsyncProcessHandler:

one for the Stack Event and one for the TU Event.

Furthermore, in a Multithread model, the AsyncProcessHandler can be called
from

Transport Layer Threads or Stack Thread, and I read that the DUM API isn't

thread safe, so we can't safely use the DUM API in this AsyncProcessHandler.

Thus the DumProcessHandler sample gived in the Dum project seems not be used

safely in a multithread model.

In the multithread model, the AsyncProcessHandler could just wake up the DUM

thread via a System Event on which it call the proccess() method.

Thus a DUM thread could wait on external event and be waked up by the stack

only when a TU event is avaible, without continuously pooling on process
method.

Are you agree with that or am I in a wrong way ?

Thanks for your answers

Julien

----- Original Message ----- 

From: derek <mailto:derek at xten.com>  

To: resiprocate-devel at list.sipfoundry.org 

Sent: Wednesday, March 16, 2005 9:49 PM

Subject: [reSIProcate] Merged in my xten-async branch, some minor API
changes

At long last this is merged in, along with some other fixes that I spotted
along the way. Here's the commit log, mangled a bit by outlook.

Major changes:

Alternative "async/external" Processing Model

The SipStack & DUM can now run w/out being in a build/select/process

loop.  This is accomplished witht ransports that provide their own cycles,
as well

as an external timer api.  The SipStack is constructed w/ an

AsyncProcessHandler which gets notified when a message is put into the

StateMacFifo, or when SipStack::postMs or SipStack::post is called.  This
can be

optimized a bit more; in some cases only a timer adjustment may be required,
but

the stack might not require cycles.  DumProcessHandler, located in the Dum

directory, is a example of how to use this.  Note that it provides ares w/ a
50

ms timer when there is an active query.  DnsInterface now has a
requiresProcess

method to facilitate this; it should possibly become another

getTimeTillNextProcess method.

Transport Refactoring/Cleanup

TransportSelector now only understands objects that derive from Transport.
The

SipStack is responsible for the Transport Factory behaviour of addTransport.
A

lot of the Transport has moved into InternalTransport, to keep the Transport

abstraction clean.  Also, the tcp transports have been cleaned up; most of
dlb's

rant in ConnectionBase.hxx has been answered. 

IpVersion vs Bool IpV4

bool is no longer used to represnt IpVersion, the enum is used in tuple and

anywhere else I spotted it.

The result of this merge/cleanup has been regressed; I still need to
re-write

testTransportSelector.cxx.  The async model has not been used yet with the

result of this merge, but it was used extensively in the branch.

--Derek

  _____  

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

This message contains information that may be privileged or confidential and
is the property of the Capgemini Group. It is intended only for the person
to whom it is addressed. If you are not the intended recipient, you are not
authorized to read, print, retain, copy, disseminate, distribute, or use
this message or any part thereof. If you receive this message in error,
please notify the sender immediately and delete all copies of this message.

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