[erlang-questions] Diameter service restart

[Chandru]

Hi,

One way is to create virtual interfaces on your box so that each of your
application is exposed via a different IP/Port combination. That way when
you stop a service, only the transport connections associated with that
service would get torn down.

It wouldn't be right to allow you to stop an application while keeping the
associated transport up. From the peer's point of view, after the CER/CEA
dialogue, it is expected that you will be able to field requests for all
applications which you advertised in your CEA.

I can't imagine a valid scenario where this kind of feature would be
required. Can you please elaborate?

Chandru


On 26 August 2015 at 14:09, Kirill Ratkin <kvratkin@REDACTED> wrote:

> Hi all.
>
> I'm working with application which implements several Diameter
> Applications (Gy, Cx and so on).
> When I start all Dia Applications together in diameter:start_service
> function then all Applications works well.
>
> But I need a little bit more. I want to start one Application (for example
> Gy) and provide API function from my module to add/remove another
> Applications (for example Cx) "on fly" without stop_service/start_service.
>
> Yes, I know every Application has code generated from dictionary file. How
> I understand this code can be re-loaded automatically by code_server (in
> theory). And then Diameter stack could use call_back module of new added
> Application.
>
> I probably read all manuals and examples of Diameter library but I didn't
> manager to find similar functionality.
>
> Guys, who knows is it possible or not?
>
> P.S. yes, solution with stop_service/start_service works but stop_service
> closes tcp/sctp sockets and start_service creates it again sending CER as
> required by RFC. I'd eliminate socket destruction. Just sending CER would
> be Ok. I afraid some vendors can dislike such situation with transport ...
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150826/22b12083/attachment.htm>