Re: Conflicting invocation constraints

On Feb 14, 2007, at 10:07 AM, Mark Brouwer wrote:

> So when the server imposed constraints is Confidentiality.YES
> (requirement) and the client set constraints is Confidentiality.NO
> (requirement) that would result in no call context as you won't be
> able
> to find a cipher suite that can satisfy both?

Right.

> I did find getCallContext() but I was also looking for an exception
> that
> would make clear there was a conflict. The end result is the same,
> maybe
> with the only disadvantage that a client is not told as part of its
> exception the constraints couldn't be satisfied due to a conflict.

It would certainly be possible for the implementation to provide
better exception messages for the conflict cases that it
understands.  Note that some of the cases can be complicated,
though.  For example, the suites that take DSA keys all perform
encryption, so requiring Confidentiality.NO will fail if you have the
wrong key type.  Again, the implementation could know about this, but
it would take additional work to sort out.

> But what happens when you have a connection timeout constraints
> imposed
> by the server of 10000ms (requirement) and a connection timeout
> constraints of 500ms (requirement) by the client. I would call this a
> conflict but both seems to be able to be satisfied, which one will be
> chosen, or will this result in no call context as well?

The ConnectionRelativeTime and ConnectionAbsoluteTime constraints
both specify maximums for the amount or latest time by which a
connection needs to be established.  If there are two of these
constraints, then the most restrictive one wins, but both can be
satisfied.

>> As a side note, in pre-release versions of the code, constraints did
>> have a notion of conflicting constraints, but this turned out to be
>> both quite complicated and not really right.
>
> :-) feels like the situation I'm in, constraining remote method
> invocations by concepts that can be understood by most people and
> that translates to invocation constraints that doesn't conflict with
> each-other.
>
> I had hoped by looking at the 'conflict detection' code I would
> have had
> another source of teaching material in applying constraints.

I think it is a reasonable approach to compare constraints with the
know modes that the transport can support, so it can serve as a
model, at least for the situations where it applies.

The Kerberos endpoint implementation may take more of the approach
that you are looking for here.

- Tim

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]