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
