Re: [Opengrads-devel] Java client/server

[pedro t. <ped...@ya...>]

hi Arlindo,

Yes, I think it is ok, I should be able to help with the Java implementation.  

In regard to 'would the server be able to handle requests from multiple clients', the current description 'GBS' will not.  To handle multiple clients, usually what is done is (using traditional Unix client-server design, at least from old Unix code I seen):  a parent process which we call 'mother' is initially started, the 'mother' is listening on a port, when a client make a connection on that port, the mother will create a child process(via fork()).  In the child process, it does a exec() to run the actual code (in this case, it would be the 'GBS').  For each client connection, there is 'GBS' instance interacting with that remote client. When the remote client exits, the child process (e.g., GBS instance) terminates and resource is freed.  The mother does not exit, it is always running and listening on the port for an incoming connection.    

Pedro



--- On Mon, 1/19/09, Arlindo da Silva <da...@al...> wrote:
From: Arlindo da Silva <da...@al...>
Subject: Re: Java client/server
To: "pedro tsai" <ped...@ya...>
Cc: ope...@li...
Date: Monday, January 19, 2009, 11:21 AM

Pedro,

   This looks like a great design. I like the fact that the GrADS Backend Server (let's call it GBS) uses sockets, so in principle the front end could be implemented in other languages, for example, python. This is good because later on I could hook up PyGrADS to the GBS as well.  For performance critical applications, at the expense of security, one might be able to replace the NextVM portion with the actual GrADS C implementation with some form of JNI glue. A quick question: would the server be able to handle requests from multiple clients? This would be important if one wants to provide GBS as a web service. Also, having the GBS and a thin client as you propose would make it very feasible to have a cell phone implementation of the client. I'd love to plan a route on Google Maps and have a Meteogram plotted along the route.


  Would you have any time to help out with the Java implementation? I have limited Java/socket programming experience. I suppose you could reuse some of your previous Java code, correct?

  Thank you for the thoughtful response.


  Cheers!

     Arlindo


On Mon, Jan 19, 2009 at 12:22 PM, pedro tsai <ped...@ya...> wrote:


Dear Arlindo,

Here is my suggestion/approach regarding this issue about client-server and non-blocking behavior.   

For the purpose of discussion, I will use the term java-client process 
and c-code server process.  These 2 processes can be running on 

different machines or on the same machine.

1. For the Java client process, I think this process needs 2 execution 
contexts (e.g, 2 threads).  
   
   (a) thread 1 is a command processor, this corresponds to the part of code that use

       JReadline to get the user input:
       
    if ((cmd = reader.readLine("ga-> "))==null) break;
            rc =
 ga.call("gaCmd",ga.strdup(cmd));

        Now instead of calling GrADS runtime under NextedVM,  it will sends the
        command to the C-code server process.

    if ((cmd = reader.readLine("ga-> "))==null) break;

            rc = Send_command_and_c_code_process("gaCmd",ga.strdup(cmd));

    For now, we don't need the detail for 'Send_comand_to_c_code_process', 
        most likely it will be implemented on standard 'socket API' in Java,

        using TCP or UDP connection.

   (b) thread 2 is described later.

2. C-code server process :  this process consists of 'grads c-code' component 
   running under NextedVM and a wrapper layer, this is the
 'GradsVM' wrapper
   in your e-mail:

   (a) In the GradsVM component, it performs 'socket' read function 
       get the command string from the Java client process, and it then
       calls 'ga.call("gaCmd,ga.strdup(cmd))' to pass the command

       to the 'grads c-code'. 

   (b) After the execution is done by 'grads c-code', the graphics primitives
       commnads are returned to the GradsVM wrapper via the callback function 
       (this corrsponds to the Runtime.CallJavaCB() in the existing

       JGrads.java code).  In this function, we will buffer the graphics 
       primitive commands,  for example,  

       In the
 Runtime.CallJavaCB(),  if we receive a GXDWID, instead of 
       calling g.gxdwid(a), we will add the GXDWID command and its 
       parameters to the buffer:

          (......, 
          GXDWID+parameters,

                  GXDMOV+parameters,
          GXDDRW+parameters, 
          GXDFRM
          )

       When the graphics primitive 'GXDFRM' is encountered, then the content of
       the buffer can be send back to the Java client process 

       (again, omitting the detail for network socket
 operation)

3.  In the Java client process, the second execution context (thread 2) is 
    the graphics primitives processing thread.
    
    (a) In thread 2, it listen for graphics primitives requests from the 

        C-code server process.  When the requests arrive, it processes
        the graphics primitive commands by calling gxJ() functions: 

    g.gxdwid, g.gxdmov, ..... gxdfrm.

Attached files are drawing showing this program flow (If you can not open the vizio file, then just open jpeg file).


best regards,

Pedro




--- On Thu, 1/15/09, Arlindo da Silva <da...@al...> wrote:

From: Arlindo da Silva
 <da...@al...>
Subject: Java client/server
To: ped...@ya...
Cc: ope...@li...

Date: Thursday, January 15, 2009, 8:42 AM

Dear Pedro,

I have a question for you regarding a client/server split of GrADS, much along the lines of what youy did 10 years ago.  My main
interest is to be able to run the core GrADS on the machine where the
data resides and do the plotting locally on my laptop while sipping coffee
at Starbucks. Of course OPeNDAP allow some of this functionality, but doing server-side operations in GDS is just a bit restricted. 



My current approach for grads.jar is  based on NestedVM and creates sort of a "single
executable". Strictly speaking, it is not client-server. However, there
is a very natural "fold" for a client/server split: most of the system
is based on the C sources compiled into java byte code through
NestedVM; I'll refer to this part of the system loosely as the "C code". There are only 2 files with actual java code: 

JGrads.java which contains main(): the NestedVM class
"grads" is called several times: once for initialization and then in a
while loop (function GaCmd) so that I can use JLine (readline
replacement). 

  gxJ.java: adaption of your original code. These gets called from within the "C code" through a  callback setup that gets done in JGrads.java.
Therefore, one could say that the "C code" part of the system is the
server, while JGrads.java is the client. This split is very different
from what you have conceived originally because now most of the graphics is
done server-side, only the final rendering using the gx primitives
is done client-side. A good thing about it is that any improvements Brian makes to the plotting routines are readily available. The graphics primitives are much less likely to change, so it is much easier to maintain. On the down side, the server does most of  the work. 



Now, the thorny issue: how to handle the fact that the "C code" calls back
java for the graphics primitives.  Although it is not setup this way right now,
perhaps we could have some non-blocking way of calling GaCmd with
subsequent queries to the server for the graphics primitives requests/end
of command events. I was thinking about a GradsVM.java class that wraps
around the "C code " and provides what is necessary for implementing
this (for example, buffering the graphics primitives' requests.) 



How would you do it? I have close to zero experience in Java, there is probably more elegant ways of doing this.

   Thanks,

        Arlindo

-- 
Arlindo da Silva
da...@al...








      


-- 
Arlindo da Silva
da...@al...