river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: roadmap
Date Mon, 01 Feb 2010 19:46:59 GMT
Sim IJskes - QCG wrote:
> Peter Firmstone wrote:
>> Similar to a VPN, but without the Private Part, VPN's use IPSec, 
>> which is a low level OS kernel and router implementation that TCP/IP 
>> utilises which require forward planning and administration.  
> I'm not clear on what the point is here, but it is my intention to 
> create something that can be used in a CUG deployment. So that the 
> owner of the infrastructure can prohibit use of their 'proxyservers' 
> to systems outside the CUG.
>> Instead we could communicate over ordinary public networks without
>> any special network admin intervention.
> I'm with you!
>> This does raise privacy issues though for serialization or message
>> streams, however secure JERI has mechanisms to handle those.
> Exactly, you cannot provide proxies in the wild without some kind of 
> verification. Thats why i keep returning to things analogous to 
> tunnels/VPNs etc. Because i want a TLS session end to end.
>> That is of course if Serialization is used for communication. 
>> Compressed Serialized binary data is the fastest way to communicate
>> over bandwidth restricted and high latency networks.
> BTW pluggable marshallers, this could provide us for a place to put an 
> auto-exporter in. We could with annotations/interfaces signal verify 
> the intent. (i'm sure i'm not the first one thinking that).
>> For smart proxy implementations we would want the client to be able 
>> to download the marshalled smart proxy from a lookup service and 
>> download the bytecode from a codebase service (it would be easier if 
>> the code base is public), where the smart proxy itself uses its 
>> internal reflective proxy (RMI JERI) to communicate with the private 
>> service via the listening post.  The listening post would just be 
>> relaying the methods / messages while keeping the communication lines 
>> (NAT gateway ports) open between it, the smart proxy and its server.
>> Perhaps JERI itself could utilise some sort of Relay listening post 
>> service?
> Exactly, i was only talking about a proxy in terms of JERI. I think we 
> now have the proper name for it. Jeri Relay Service (JRS)?
> We can also create a standard codebase service, which can (off-course) 
> also be exported over the JRS.
> Gr. Sim

View raw message