Subject: [AAA-WG]: RE: API, latest draft

From: James Kempf <[email-masked]>
Date: Tue, 24 Apr 2001 11:48:58 -0700 (PDT)

Hi Brian,

>
>from AAASessionManager, section 4.4.1:
>>      public int getSessionCode(InetAddress host)
>>
>>   Return the session code corresponding to the host. If no session is
>>   currently active with the host, return NO_SESSION_CODE
>
>It is possible (and VERY likely) for several AAA sessions to exist with one AAA 
peer.  Ergo, an IP is an insufficient key for session lookups.  Alternative: 
return ALL sessions associated w/given peer.  (This presumes that the API's 
internal session code is one-to-one w/AAA Session Identifier).

I guess I am having some trouble seeing what value there would be 
in getting back all the session identifiers. How would the application
decide which to use?

The original idea behind this method was that there would be one session
active for a particular AAA peer IP address at any one time in an active virtual
machine. If, as you say, there should be more than one session, perhaps
one session per application, then I think we ought to simply drop
this method. An application is then responsible for opening a separate session,
and keeping track of the session id, each application gets a separate
session.

>
>~~~
>
>AAAClientSessionManager:
>>      public static
>>      registerUnsolictedExceptionHandler(UnsolicitedExceptionHandler handler)
>>
>>   Register a handler for exceptions that occur during input of unsolicited
>>   messages, for example, parse errors. This handler is global for all
>>   sessions and all client application code in this executing instance of the
>>   Java virtual machine.
>
>How about "registerUnsolicitedMessageExceptionHandler()"?  Yes, it is a bit 
long; but still, no one solicits an exception, right?  If the method name stays, 
fix the typo: "registerUnsolictedExceptionHandler" -> 
"registerUnsolicitedExceptionHandler".

OK.

>
>Naming aside, I think parse errors should not be listed as an example for an 
exceptional condition that can be handled.  A parse error seems like a protocol 
issue that should be handled internal to the library.  If the protocol calls for 
an MRI to be sent, the library should do it, and not rely on the 
UnsolicitedExceptionHandler to take this action.  If it's the case that the 
handler is called in addition to library handling, that's better, but I still 
have to wonder why anyone would want to know about messages that have parse 
errors.  (The above goes the same for solicited messages, too, for that matter).

Suppose a Diameter client gets an unsolicited message that is improperly
formatted. The message parsing code detects this and throws
an exception. Where should the exception be handled?

One possible way it could be handled is to simply write an error report
to a log file (and J2EE 1.4 has some new support for logging,  I'm
told). However, if the application is a GUI application, the application
code may want to inform the user that something is wrong with their
Diameter connection so the user can take immediate action. 

This method lets the application code decide how to handle such errors.

I'm not sure I understand your comment about an MRI being sent. I don't
see any Diameter messaging being done via UnsolicitedMessageExceptionHandler, 
I think it is only for reporting the error.  

With regard to why somebody should know about messages with parse errors,
presumably because it means the Diameter peer implementation is faulty.
But maybe that wasn't such a good example, perhaps you could suggest something
better.

		jak