Re: Using JERI over the internet

Gregg Wonderly wrote:
> Mark Brouwer wrote:
>> Gregg Wonderly wrote:
>>> A predominate issue with this type of problem, is that the server
>>> will end up
>>> with many, idle socket connections from each client, which can create
>>> resource issues if not properly administrated.
>>
>> An issue will be how you can have asymmetric authentication/encryption
>> in a secure tunnel, probably there is a better word to describe what I
>> mean but I hope you get what I mean.
>
> A callback path should be identical to a return value from a client to
> server invocation shouldn't it?

Hi Gregg,

I don't think 'should' is the right word. Probably reality is that it
is, but the programming model allows for it to be asymmetric and I was
wondering how one should deal with that.

I might be that a lookup server requires strong client authentication
when that entity tries to register for events, but it doesn't require
strong 'server' authentication when publishing the events. In fact the
symmetric model is effective in the inverted event model and IIRC there
was one person who found that kind of awkward.

>                                     Do you want the servers identity to
> enter the clients callback context?

I'm not sure about what you are exactly asking, could you elaborate Gregg?

 >                                    The endpoint implementation should
> be able to manage all identity associated with data flowing right?

I can't give an answer. All I'm holding on is this remark in the spec
for Jini ERI Multiplexing Protocol:

"Note that it is explicitly not a goal of the design at this time to
support bi-directional request initiation over a single connection, such
as for making remote "callbacks" over an incoming connection, because of
the endpoint identification, security, and connection life cycle issues
that are consequences of such a goal"

And if something is very difficult I always shout "because of security"
because then most people back-off as most of the time nobody understands ;-)

>
>> Another issue is likely that codebase reachability is not solved by such
>> an endpoint implementation.
>
> I assume you are talking about a server being able to download code from
> a client?

Yes

>           I always try and design my APIs to not require customization
> of parameter types for calls into the server, which I can not account
> for in classes that I can install on the server.

I agree that is a good design goal, but I think when your client is a
listener of events from a server it is often hard not to implement that
as a proper specialized proxy which will require code downloading by the
server.

In such a case I prefer an inverted event model for which it is
completely clear that the listener is local such as what I did with
ServiceRegistrarX.

 >                                               I then set the clients
> codebase to be localhost based so that the server always downloads from
> itself.

What if the server doesn't have the code? Although I agree with
minimizing code downloading when not required, if the goal becomes
preventing from code downloading taking place I wonder whether Jini is
the right technology for such a case at this moment.
--
Mark

--------------------------------------------------------------------------
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]