<div dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I can't imagine a valid scenario where this kind of feature would be required. Can you please elaborate?</div><div><br></div><div>Chandru</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 August 2015 at 14:09, Kirill Ratkin <span dir="ltr"><<a href="mailto:kvratkin@gmail.com" target="_blank">kvratkin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi all.<br><br></div>I'm working with application which implements several Diameter Applications (Gy, Cx and so on).<br></div>When I start all Dia Applications together in diameter:start_service function then all Applications works well.<br><br></div>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.<br><br></div><div>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.<br></div><div><br></div><div>I probably read all manuals and examples of Diameter library but I didn't manager to find similar functionality.<br><br></div><div>Guys, who knows is it possible or not?<br><br></div><div>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 ...<br></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>