Running the native SST examples
It is important to realize that code above did not create Ping and Pong for you, it simply configured and started the necessary Server Smalltalk infrastructure.
To run your example you will need two objects that talk to each other, a Ping and a Pong. Both Ping and Pong are instances of SstPingPong*, however their behavior varies (i.e. what messages they send) depending on whether they are playing the role of Ping or the role of Pong. What role they play is determined by which machine they are on.
Further, when a machine is set up as Pong, it will make available a factory object that is responsible for creating the actual Pong object. In most of the examples, the Pong Factory is the the class of your example, e.g. SstPingPongByValue.
Now that the example's infrastructure is ready, the next step is to create ping-pong objects on both machines. This could be done manually or, as a convenience to get you up and running faster, the Ping-Pong examples have provided a helper method which does all the work.
You will want to send further messages to the ping-pong object on Ping; so you might like to open an inspector on the result of the following. On Ping you can evaluate:
SstPingPong* createPingAndPong
This method sends a message to the well-known Pong Factory (on the Pong machine) that creates and exports a ping-pong object (known as Pong). A reference to the created object (Pong) is then returned and retained in the local ping-pong object (Ping) which is itself returned from the method. Therefore, by inspecting the result of this code, you will be looking at an instance of SstPingPong* that represents Ping. It contains an instance variable named remote that holds onto either a reference to Pong (i.e. in the ByReference examples) or an identifier that can be used to look up Pong in the remote space (i.e. in the ByValue examples). This is how Ping knows about Pong and visa-versa. Since they are now known to each other, they can communicate via messages, just as though they were both resided in the same image.
If you would like to see what goes on during setup, put a breakpoint in the setupPing:pinging and setupPong:ponging methods of the example you are running. Other interesting methods include createPingAndPong and createFor:.
Having set things up and created the objects, the example can be run by sending start: 3 with: #(1 2 3 4 5) to the result of the createPingAndPong method on Ping. Alternatively, you can combine the two operations into one. For example, evaluate:
SstPingPong* createPingAndPong start: 3 with: #(1 2 3 4 5)
Note that there is nothing unique about the values chosen for start:with:. The required arguments are an integer for the start: part and any object you like for the with: part of the operation.
Running the example prints a series of messages on the Transcript of each image. Notice that the value received decreases with each message. The information about the process relates to the process which is running the current request. This will become more interesting as you begin to understand the different dispatching techniques used within Server Smalltalk.
All of the ping-pong examples do exactly the same message sends but the requests are handled differently depending on how the system is configured. This request handling can be studied by looking at the process information in the Transcript output. While it is discussed in more detail below, the examples demonstrate, among other things, the ability to have each request run in a single process (SstPingPongByValue), in one of a pool of processes (SstPingPongByReference) or maintaining logical process identity across multiple remote processes (SstPingPongLP).
Once you have played with an example be sure to clean up the related SST infrastructure and example objects for the example class you ran. Do this on both Ping and Pong using:
SstPingPong* cleanUpPingPong
Last modified date: 01/29/2015