[reSIProcate] Removing Transport
Nilay Tripathi
nilay.linux at gmail.com
Fri Dec 8 23:45:58 CST 2006
Hi,
Ok ... its not about deleting transport, but shutting-down the transport
as Byron mentioned precisely. Yeah there would be repeated re-configuration,
but that is the intent for shutting down the transport and adding a new as
per the
new configuration. It would be a pain to remove the SIP stack object and DUM
object every time I want to modify (closing down older one, and adding new
transport)
transport. In that sense it is surely a desirable stuff!
I understand doing it with handles will really require a LOT of work, but
can we
consider failing the DUM operation if the asked transport is not found at
transport.
I feel that there should not be a state-bloat in this case at DUM.
I am not pretty sure of this theory, but would really appreciate if you can
give some
thought and validate it.
Thanks for your time :)
Nilay
On 12/9/06, Matthias Moetje <moetje at terasens.com> wrote:
>
> Byron,
>
> I would also be very intered in the ability to
> dynamically remove transports. My opinion though,
> is that invalidating transports without deletion
> would be just fine. Changing transports is a task
> that is usually done rarely. Some dead transports
> flying around wouldn't do any harm.
> Sure, there may be rare cases when someone might
> want to do this frequently, but would these rare
> cases be worth to undertake so much effort? I think
> the "shut down" solution would be fine for most.
> What do others think?
>
> Best regards
>
> Matthias Moetje
> ______________________________________________
>
> TERASENS GmbH Phone: +49.89.143370-0
> Augustenstraße 24 Fax: +49.89.143370-22
> 80333 Munich e-mail: info at terasens.com
> GERMANY Web: www.terasens.com
> ______________________________________________
>
> > -----Original Message-----
> > From: resiprocate-devel-bounces at list.resiprocate.org
> > [mailto:resiprocate-devel-bounces at list.resiprocate.org] On
> > Behalf Of Byron Campen
> > Sent: Friday, December 08, 2006 3:37 PM
> > To: Nilay Tripathi
> > Cc: resiprocate-devel at list.resiprocate.org
> > Subject: Re: [reSIProcate] Removing Transport
> >
> > Currently there is no way to remove transports after
> > they have been added.
> >
> > Allowing for the removal of a transport could end up
> > being very tricky. There are lots and lots of Transport*
> > (mostly in Tuple) floating around, and deleting a Transport
> > will almost certainly invalidate lots of them. If we were to
> > "shut down" transports (without actually deleting them), this
> > would be safer, but we could end up with state-bloat after
> > repeated re-configuration. Removing all of these pointers and
> > replacing them with some sort of handle could work, but a lot
> > of code would have to be touched.
> >
> > Mind you, this is still something I eventually intend
> > to do, but I have a lot on my plate to finish first.
> >
> > Best regards,
> > Byron Campen
> >
> > > Hi All,
> > >
> > > I was looking for a way to remove an added transport at the
> > > application.
> > > Actually, I want to be able to either remove or update a transport
> > > within the application, so that I do not have to close it down.
> > >
> > > It seems some api like removeTransport( ) was there in DUM
> > till 0.9.0.
> > > (I am working at 1.0 now) which is not there in new
> > versions. And as
> > > per my understanding goes, the transport is finally removed
> > from the
> > > map at TUSelector when SipStack destructor is called during
> > shutdown.
> > >
> > > Please throw some light, if there is any other way that I can
> > > remove/update transport or will I have to close down SIP
> > Stack and DUM
> > > each time to do it.
> > >
> > > Thanks,
> > > Nilay
> > > _______________________________________________
> > > resiprocate-devel mailing list
> > > resiprocate-devel at list.resiprocate.org
> > > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel at list.resiprocate.org
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061209/09d90f58/attachment.htm>
More information about the resiprocate-devel
mailing list