On Mon, Feb 15, 2010 at 1:11 PM, Don Guinn <[email protected]> wrote: > I don't think it would take much to actually move problems once we have > other J sessions available. The socket interface it there. 3!:1 and 3!:2 > provide the tool to transfer the data in a generalized way. Sockets provide > easy notification to coordinate between instances of J. Big problems I see > are security and being able to start J remotely. I don't know where to start > with them.
To start J remotely you need to create a "J server" which can spawn J sessions on that machine. To do this securely you need to have some sort of secure connection mechanism. The primary risk you need to defend against is unauthorized clients. The ideal mechanism here involves a collection of machines which is not connected to the internet. A slightly weaker version allows some machines to be connected to the internet but black listing them, such that they are not allowed to be clients to the "J server" (they can be servers for other J sessions). Other variations are also possible (for example, giving clients secret keys and using them to generate hashes against recent timestamps and executable sentences). In other words: client and server: hash=: md5sum secret,timestamp,sentence (hash sent from client must match hash generated on server). (server also rejects unreasonable timestamps). Except, I think we have better options than md5sum. FYI, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
