Tom Hobbs wrote:
Always communicating in a separate JVM is going to have obvious performance
costs. Do we know what they are and are they acceptable?
It's hard to say at this stage, without an implementation, but it will
consume more resources.
I figure a good compromise would be that each registrar proxy be
responsible for it's own jvm and any services it provides. The client
would be run from it's own jvm.
A separate JVM for remote code reduces the amount of client and platform
code visible to proxy's. Shared class (static) variables are not
possible between client and downloaded code. This would also allow
different conflicting libraries to be kept separate.
The Isolates API would be more desirable, but not available.
Just an experiment at this stage, time will tell... anyone wanting to
help, sing out.
Is going to be
easy to turn off for.people who trust what they're downloading an don't want
to pay the perf costs etc?
I hope so, haven't considered configuration at this stage.
Cheers,
Peter.
On 11 Jun 2011 20:49, "Peter Firmstone" <j...@zeus.net.au> wrote:
Dan Creswell wrote:
On 8 June 2011 05:31, Peter Firmstone <j...@zeus.net.au> wrote:
Phoenix wakes (Activates) up a Service when it's required on the server
side. I haven't thought of a good name for it, but unlike Phoenix, the
concept is to perform discovery, lookup and execute smart proxy's on
behalf
of the client jvm at the client node, although I concede you could run a
service from it also. Reflective proxy's would be used to make smart
proxy's appear to the client as thought they're running in the same jvm.
Process has some peculiarities when it comes to input and output
streams,
they cannot block and thus require threads and buffers to ensure io
streams
are always drained. Process uses streams over operating system pipes to
communicate between the primary jvm and subprocess jvm.
I've been toying around with some Jeri endpoints, specifically for
Process
streams and pipes, still I'm not sure if I should consider it a secure
method of communication just because it's local. Do you think I should
encrypt the streams?
So you want to use pipes?
The answer to whether you want to encrypt the streams or not is down
to what kind of threat you're trying to mitigate. And the threats
possible are determined by what solution you adopt. Pipes are
basically shared memory, what kind of attacks are you worrying about
in that scenario?
I guess the attacker would be someone who already has user access to a
system, if that's the case, the game's probably lost for most systems.
I'm trying to consider the semantics of such a connection with regard to
InvocationConstratints.
Integrity,
Confidentiality,
ServerAuthentication
ClientAuthentication.
It really doesn't support any of the above constraints, but we're not
going to use it for discovery etc..
The intended purpose is to isolate downloaded code in a separate jvm and
communicate with it using a reflective proxy.
Cheers,
Peter.
