Server Smalltalk

Network computing for Smalltalk

Running the Examples

The PingPong Examples

PingPong is the "Hello World" of distributed computing.  One machine sends a message to another which sends a message back.  This confirms that the machines are connected and speaking the same language.  The simple PingPong application also admits many variations which can be used to demonstrate different system configurations.

Server Smalltalk comes with a large number of PingPong examples.  The PingPong examples are intended to demonstrate how the facitilities of Server Smalltalk are configured and used to various effects.  They are not meant to be representative of any realworld application or to show users how to write their distributed application.

The actual examples themselves are documented in the comment of the class SstPingPong.  Below is a summary of how the examples are run.  There are separate sections for the IIOP and Java RMI examples as they also require the installation and use of middleware other than SST.

Running the Native SST PingPong Examples

All of the native PingPong examples are setup with one machine as Ping and one as Pong.  Generally the example is started from Ping.  We assume that you have two VAST 4.5 images running and the "Server Smalltalk - Examples" configuration map loaded.

In the example code, replace <ping> with the TCP host and port of the machine you are using as Ping and <pong> with that of the Pong machine.  Note that currently the examples do not run with both Ping and Pong in the same image.  You can however run two images on the same machine and chose your ports accordingly.

The steps for running the examples vary slightly but generally follow the pattern set out below:

  1. [Pong] Setup the SST infrastructure

    2.     SstPingPong* setupPong: 'tcp/<pong>' pinging: 'tcp/<ping>'
  2. [Ping] Setup the SST infrstructure

    3.     SstPingPong* setupPing: 'tcp/<ping>' pinging: 'tcp/<pong>'
  3. [Ping]Run the example

    4.     SstPingPong* createPingAndPong start: 3 with: @value
    where @count is the number of messages to send and @value is an object to pass along in the messages.
  4. [Ping+Pong] Clean up the created SST infrastructure

    5.     SstPingPong* cleanUpPingPong
The details of running specific examples and the output you should expect is described in the class comment of SstPingPong.  In addition to varying the arguments, there are several options you can load into the examples. These are detailed in the example descriptions as well.

Running the RMI PingPong examples

Server Smalltalk includes several PingPong-based examples of clients and servers written in Java. These interact with Smalltalk via RMI or IIOP. They can be run with Java systems based on JDK 1.1.6 or 1.2 Beta (note that as of this writing, the JDK 1.2 code is Beta and it is not guaranteed to interact with SST correctly).

The Java code is in the file sstjava.zip. When unzipping the file, ensure that the directory structure and long file names are preserved. Add the unzip destination directory to the Java classpath. Alternatively, it is often convenient to simply add '.' to the classpath and then change your working directory to the root Java code directory when running the examples.  If you are running from within VA for Java, the file must be unzipped and imported into your Workspace.  Add the Project into which the code was loaded to the classpath for the Workspace (see the Workspace>>Options menu).  Note that running in VA for Java is only practical for the RMI-based examples as the third-party IIOP products may or may not be integrated with VA for Java and so may not use Java code directly from the repository.

Below is a description of how to run the SST Java RMI PingPong examples.  The typical case is where one of Ping or Pong is running on a JDK VM and the other is running in VAST with SST loaded.  It is assumed that the Java code to be run (i.e., the contents of sstjava.zip) is in the Java package directory structure in the directory D:\pp (substitute your own root here) and that JDK bin directory is on the command path.

Smalltalk Ping, Java Pong

Smalltalk is used to run Ping and Java to run Pong.  As usual, the example is started from Ping (in this case, Smalltalk).
  1. [pong] Ensure that in addition to the standard paths, your classpath includes the current directory (e.g., classpath=<standard dirs>;.) or the absolute path to the directory containing your code (e.g., D:\pp).
  2. [pong] At a command prompt, change to the Java directory containing your code.

    3.     cd D:\pp
  3. [pong] Run the RMI registry on Pong.

    4.     rmiregistry
    Note that this does not need to be shutdown and restarted each time.  You must ensure that no one else is running an RMI registry or using port 1099 on your machine.  Use "netstat -an" before running the setup code and see if port 1099 is allocated.  If so, find the program using it and stop it.  RMI defaults to port 1099.
  4. [pong] Run the PingPongFactory on Pong and tell it to create instances of the desired PingPong class.

    5.     java com.ibm.sst.examples.rmi.PingPongFactory
            com.ibm.sst.examples.rmi.PingPong
  5. [ping] Setup the SST infrastructure.  For example,

    6.      SstPingPongRmi setupPing
  6. [ping] Create the ping and pong objects and start the example.

    7.      (SstPingPongRmi createPingAndPong: 'rmi://pong.com') start: 6 with: 'test'
    Where <pong.com> is the IP address/name of the machine running Pong.  Change the arguments to #start:with: to suit your needs.
  7. Look at the output on both sides and confirm expected behaviour.
  8. Run the example as many times as you like by repeating step #6.
  9. [ping] Clean up the created SST infrastructure.

    10.     SstPingPongRmi cleanUpPingPong

Java Ping, Smalltalk Pong

Java is used to run Ping and Smalltalk to run Pong.  As usual, the example is started from Ping (in this case, Java).  Remember the lanugages used for Ping and Pong are reversed below.
  1. [pong] Setup the SST infrastructure, an RMI naming service and the PingPongFactory.  For example,

    2.      SstPingPongRmi setupPong
    Note that this does not need to be shutdown and restarted each time.  You must ensure that no one else is running an RMI registry or using port 1099 on your machine.  Use "netstat -an" before running the setup code and see if port 1099 is allocated.  If so, find the program using it and stop it.  RMI defaults to port 1099.
  2. [ping] Ensure that in addition to the standard paths, your classpath includes the current directory (e.g., classpath=<standard dirs>;.) or the absolute path to the directory containing your code (e.g., D:\pp).
  3. [ping] At a command prompt, change to the Java directory containing your code.

    4.     cd D:\pp
  4. [ping] Start the example by running the appropriate Java class.

    5.      java com.ibm.sst.examples.rmi.PingPong rmi://pong.com/pingPongFactory 6 test
    Where <pong.com> is the IP address/name of the machine running Pong.  Change the arguments to suit your needs.
  5. Look at the output on both sides and confirm expected behaviour.
  6. Run the example as many times as you like by repeating step #4.
  7. [pong] Clean up the created SST infrastructure.

    8.     SstPingPongRmi cleanUpPingPong

Other PingPong examples

The other PingPong examples (e.g., PingPongExceptional) are run by substituting the corresponding example class names wherever an example class name is provided.  That is, in steps 4, 5 and 6 of the Smalltalk Ping, Java Pong configuration and steps 1 and 4 of the Java Ping, Smalltalk Pong configuration.

Of course, both the Java and Smalltalk examples can be run completely within their respective languages (e.g., Java Ping, Java Pong and Smalltalk Ping, Smalltalk Pong) by combining the above configurations accordingly.

Applets

To run the applet version of the client, start the registry and factory as above (or in Smalltalk) and open the file ppapplet.htm in an AppletViewer. Note that the HTML file assumes the root of the PingPong code hierachy is in the same directory as the HTML file itself.

Due to security restrictions, the applet must be signed to run inside the Netscape Browser. To sign an applet you need to download and install the signtool utility (v1.0) available from Netscape Developer website. You also need to have installed a copy of Netscape Communicator on your system.

  1. Generate a Test Certificate

    If you already have a certificate from a Certificate Authority then you can bypass this step. Otherwise you can use the command below to generate a test certificate to be used for development purposes

        signtool -G <certificate nick name> -d <Communicator's cert.db directory>

    Follow the prompt and at its completion, 2 files " x509.cacert" and "x509.raw" will be generated. Note: By specifying the directory of where the cert.db file is, the new certificate is automatically imported into your Communicator's certificate dabase so no extra steps are needed to import it.

  2. Requesting extra privileges

    To enable RMI callback, the applet class must import the package netscape.security.* and include the following line in its init() method before any RMI call has been made.

        netscape.security.PrivilegeManager.enablePrivilege("UniversalConnect");

    To compile the applet you will need to include java40.jar in your classpath. This file is part of Netscape Communicator distribution.

  3. Creating a signed jar archive

    Make a temporary directory into which you place all the codes that your applet needs. To make a single signed jar file use the command:

        signtool -k <certificate nick name> -Z <jarfile name>.jar
	-d <Communicator's cert.db directory> <temporary dir>

    where <temporary directory> is the place where all your applet code resides. This will create a signed jar archive which can be download by the client browser. You will need to add the following parameter ARCHIVE=<jarfile name> in the ppapplet.htm file following the CODE parameter. This is to ensure the client will get the required classes to run the applet.

  4. Making your certificate available to other people

    Before other people can grant extra privileges to your applet, they need to have your certificate in their communicator databases. One way to do this is to place the x509.cacert generated earlier in a web page as a web link. Your web server must be able to export this file as the MIME type "application/x-x509-ca-cert".

    On the browers which will download and run the signed applet, they need to click on the certificate link. This will bring up a prompt which they will need to follow to import it into their certificate database. Be sure to tick "Accept this Certificate Authority for Certifying software developers" when that question pops up.

  5. Running the applet

    When a brower downloads and runs a signed applet, a security dialog box will appear which tells you whether to grant certain privileges which the applet has asked for. The applet is identifed as belonging to a certain organisation whose certificate is in your certificate database. You can then decide whether to grant or deny that privilege.

Running the IIOP examples

To run the IIOP PingPong examples you must unzip sstjava.zip as described above. The technique for running the example depends on the Java ORB being used. There is a comment in PingPongIiop.java which gives instructions for compiling and running in various ORBs. As with the RMI example, Smalltalk- and Java-based elements can also be mixed freely using IIOP.