[2602] in java-interest
typesafe socket communcation (resending)
daemon@ATHENA.MIT.EDU (Jim Greer)
Thu Oct 5 21:43:31 1995
Date: Thu, 5 Oct 1995 18:09:08 -0500 (CDT)
From: Jim Greer <jgreer@eden.com>
To: java-interest@java.sun.com
(Forgive us if you get a duplicate of this. Mail weirdage.)
In a previous message, Arthur said that remote persistent objects were
not implementable because of a hornet's nest of security problems. We
think that we understand these security problems, but we're not sure.
We're guessing that you mean that arbitray type casts from byte[] to some
class will mean that it is possible to "lie" to the runtime system and
convince it that you're handing it one structure when in fact you're
handing it something else. However, this is only a security problem if
any of the destination fields of the class are considered pointers (i.e.
not atomic data types like int, etc.) Even if the data stream did get
typecast into a class which contained an object pointer, these object
pointers could be double checked against the heap address space during
the instanciation to avoid creating a pointer outside of the heap (i.e. a
potential virus).
Thus, we clearly don't understand the problem since Arthur is saying that
there is a big security risk here. As far as we can tell, you should be
able to implement this is a totally typesafe fashion. Additionally, it
seems like the ClassLoader class already has this problem (other than the
fact that we can't figure out how to write out a class that it knows how
to read back in! :)
We are experimenting with realtime multiuser games with clients in Java
and the servers in C++. We want to transmit a structured message to the
client and then create a class instance from the data stream. To make
this fast, we want to identify class type with an integer handle as
opposed to having some sort of magic class identification using the name
of the class or some other methodology.
Now, non-atomic data members clearly pose a major problem. If there is
some data element like an array or another object inside of this class,
then the typecast is much more compilcated. Here are two potential ways
to deal with this that would solve our problems:
1. Disallow runtime casts (i.e. generate an exception) for casts to
classes which contain non-atomic members. Disadvantage: no arrays! :(
2. Create a standardized way of linearizing/delinearizing arrays. For
example:
class MyMessage {
int a;
arraylength byte len;
byte[len] b;
}
With this information, the runtime system could typecast though some
native thing like a ClassLoader from a byte[] to a MyMessage and it would
delinearize into a traditional java structure. That is, the byte[] would
be non-linear in the heap relative to the instance MyMessage (i.e.
there's a pointer in MyMessage to b). Furthermore, it would be an
exception to write to the arraylength field.
This is kind of a kludge, but it would make efficient commincation a lot
simpler than having to write out the java equivilent of this for every
single class type. For example, the following sucks:
class 3DPoint {
int x, y, z;
static 3DPoint loadMe(DataInputStream s) {
3DPoint p = new 3DPoint();
p.x = s.readInt();
p.y = s.readInt();
p.z = s.readInt();
return p;
}
}
class MyMessage {
int a;
byte len;
3DPoint[] b;
static MyMessage loadMe(DataInputStream s) {
MyMessage myMessage = new MyMessage();
myMessage.a = s.readInt()
myMessage.len = s.readByte();
myMessage.b = new 3DPoint [len];
for (int i=0; i<len; i++) {
myMessage.b[i] = 3DPoint.loadMe (s);
}
return myMessage;
}
}
This code will work just fine under Java now, its just really really
annoying to have to keep this in sync with the class strucutres if you've
got a lot of them and they change a lot and you're trying to do it in C++
simultaneously for the server. Feel our pain! :) Grief!!!
Please help!
Thanks
Zachary Simpson
Jim Greer
Titanic Entertainment
zsimpson@eden.com
jgreer@eden.com
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
