Subject: RE: [AAA-WG]: Extension over base api as a separate process

From: James Kempf <[email-masked]>
Date: Wed, 28 Mar 2001 13:23:00 -0800 (PST)

Sreenivas,

>	1. Within a single address space, the callbacks and/or separate
>threads related to the extensions handle communication with corresponding
>"agent" processes (e.g. a QoS agent does a lot of other stuff, using
>DIAMETER protocol for AA being a small part of its overall functionality).
>
>	   The down-side of this approach is that addition of new extensions
>is static and tedious (requires modification of existing source base); it is
>possible to achieve dynamic addition of extensions using demand loading of
>shared library objects (or Java classes), but still it is a lot of burden on
>agent processes implementations to incorporate IPC of some kind to the
>DIAMETER server process. 
>

With respect to the Java API, the intent was to make the client-side
API have RPC semantics so that a client process could easily make
calls into the API without having to handle difficult interthread
communication. 

As we have discussed, and as per the note I sent to the list (without
so far any response), we are also considering doing a synchronous API
for C which would provide the same semantics for the C API.

You are correct that the client code would need to be modified, but
I have some difficulty seeing how one could enable a client to use
Diameter without doing so. Perhaps some event messaging scheme could
be used, but that is predicated on the client already using event
messaging. 

Extensions do need to be loaded, but there are plenty of ways to load
them via DLLs/shared libraries or, as you indicate in Java, demand loading.
Once the client is enabled to use Diameter, there is really little overhead
to loading an extension when the Diameter library is loaded. We currently
do not define anything in the C API to allow demand loading, as there
is no universal DLL/shared  library loading standard, but we do use
something on our platform. We have a configuration file that contains
a list of shared libraries to load when the server starts. These
shared libraries are the extensions that the server will deal with.
We can put a property into the Java API that has a list of extension
libraries to load. The client API currently doesn't need this, the
assumption being that the client will allow the classes to be demand loaded,
but when the Java server side API is complete, it might need the property.

>	2. Each extension is a process by itself; but then all of them can
>not accept requests on the same specific port: thus, this alternative is not
>really an option
>

Agreed.

>	3. The implementation itself involves multiple processes, each
>linked with the base API; one of the processes performs part of DIAMETER
>server function (proxying within the host only), while the others perform
>the other server function (performing authentication and/or authorization
>per requests routed by the aforementioned proxying server process) and other
>client functions.
>
>	   Clearly, this involves a lot of complication on routing requests
>(by the proxying server process) by means of IPC, sharing dictionary and
>other data, presenting one DIAMETER peer image to other peers, etc.
>

I have difficulty seeing what this would by you beyond using a single
multithreaded process.

The only reason I could see for using multiple processes is if you 
are on an operating system that doesn't allow multiple threads.
It seems to me structurally cleaner to have a base Diameter server
that handes the required extensions and allow optional extensions to
be dynamically linked as libraries. 

		jak

---

From: James Kempf <[email-masked]>
Date: Wed, 28 Mar 2001 13:25:39 -0800 (PST)

Ruslan,

>>	It's expected that this API will universal for all platform?

Having a universal API achieves source code portability, which generally
tends to accelerate the spread of a technology, but it is not
as important as protocol interoperability (without which the implementation
is simply broken).

There are likely those who will implement the API, those who won't, and
those who will extend it.

>	Is there a hope to get AST-driven API ? Or it will be a traditional 
unix-style coded
>blocking calls?

What do you mean by AST? Currently, the C API is asynchronous, we are
considering doing a synchronous API.

		jak

---

From: [email-masked]
Date: Wed, 28 Mar 2001 15:43:23 -0600

James,

Thanks for the comments.

On item 3 below, the reason to use multiple processes not be solely due to
lack of support for multiple threads. A process per an extension allows
development and deployment independence from other extension
implementations.

We face a situation where a Mobile-IP module has a lot of Mobile-IP specific
functionality and a very little component uses DIAMETER for AA: clearly,
bundling the whole module as "Mobile-IP extension" works, but can affect
both the DIAMETER server's and the Mobile-IP module's performance. For this
reason, we are considering the Mobile-IP module be its own process, that has
part of the DIAMETER server functionality (i.e., responding to AA requests),
while the other part of DIAMETER functionality (accepting AA requests and
proxying) is implemented as another process.

I do agree that having all extensions in a single address space (process) is
good enough in many cases; but the above consideration has driven the
earlier posting.

Regards,
Sreenivas

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Wednesday,March 28,2001 15:23
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Extension over base api as a separate process

Sreenivas,

=== snip ===

		jak