(1) Running the first SeMoA server
- After standard SeMoA settings have been given once (see SeMoA-Starter), the starter GUI can be skipped.
- Change to your semoa folder and start the demo1 server, e.g. by typing: java -jar semoa-launcher.jar -rc etc/demo1.conf.
- You should see the server booting. Click here to view a sample output. When the keymaster
component is run, a small window should pop up and ask for a password. Type "semoa.org".
- After some seconds you should be greeted with SeMoA's command prompt. Type in "why" and see if any exception is reported. If everything went fine then "No stack trace." is printed.
Ready.
> Type 'info' to get some initial help. <
/:0> why
No stack trace.
/:1>
(2) Run a second SeMoA server
- Get on a second machine or just a second shell window, and repeat the process for the demo2 server in your semoa folder by typing: java -jar semoa-launcher.jar -rc etc/demo2.conf. Again, the password is "semoa.org".
- The second machine must be on the same local area network (LAN) as the first one, for the SeMoA servers to automatically recognize each other.
- If your home is mounted from a file server then you don't need a second SeMoA installation.
- With the default SeMoA configuration from the Web site you may start SeMoA servers with four different identifications (demo1, demo2, demo3, and demo4)
- These identities base on four keystores with three different cryptographic public/private key pairs (for authentication, signature generation, and encryption).
- Some more details about the local server identity can be printed using the command alias ship to trigger the Simple Host Information Protocol (SHIP) service of SeMoA.
/:0> ship
Printing: /network/ship
Name : de.fhg.igd.semoa.net.ship.ShipServer
Info : Server for handling SHIP requests
Author : Ulrich Pinsdorf
Revision: $Id: ShipServer.java 1771 2006-05-05 10:02:06Z jpeters $
Daemon info
-----------
Local URL: ship://169.0.0.2:55002
Enabled : true
Capacity : 1
Max size : 64535
Requests : 0
Good : 0
Bad : 0 (0%)
Configuration
-------------
comm.pod.acl --> FIPA ACL
comm.pod.url --> pod://169.0.0.2:55042
comm.pods.acl --> FIPA ACL
comm.pods.url --> pods://169.0.0.2:55052
interop.jade.lc --> de.fhg.igd.semoa.interop.jade.JadeLifecycle
interop.jade.type --> Java
interop.semoa.lc --> de.fhg.igd.semoa.agent.DefaultLifecycle
interop.semoa.type --> Java
interop.tracy.lc --> de.fhg.igd.semoa.interop.tracy.TracyLifecycle
interop.tracy.type --> Java
location.address --> Fraunhoferstrasse 5
location.city --> Darmstadt
location.country --> Germany
location.gps.lat --> 49.9N
location.gps.long --> 8.7E
location.room --> 118
location.state --> Hessen
location.zip --> 64283
network.httpd.url --> http://169.0.0.2:8082
network.httpsd.url --> https://169.0.0.2:8882
network.rshd.url -->
network.sshd.url --> ssh://169.0.0.2:55072
owner.dn --> CN="Demo 2", OU="Users", O="SeMoA", L="Darmstadt", ST="Hessen", C="DE"
platform.purpose --> Development/Test
semoa.version --> SeMoA 2.0 - SeMoA-Distribution-060625
transport.in.raw.max --> 262144
transport.in.raw.url --> raw://169.0.0.2:55012
transport.in.raws.max --> 262144
transport.in.raws.url --> raws://169.0.0.2:55022
transport.receipt.url -->
Number of objects printed: 1
(3) Check if both servers see each other
- Stay at the second machine, and type in the command alias vicinity. This should cause something similar to the output below.
- The important line is the one below "LAN info". It should report the X.509 Distinguished Name of the demo1 server.
- The vicinity service reports all servers it senses on your LAN but not itself. Type in the command also on the demo1 server. The Distinguished Name that is reported should be "CN=Demo 2, L=Darmstadt, ST=Hessen, O=SeMoA, OU=Users, C=DE".
- You may kill either server with the command exit and see that its entry no longer exists when the vicinity list is printed again on the other server. A few seconds after booting the server again, its entry reappears.
- As alternative to monitor and control SeMoA via its command shell, you may start the graphical control interface Envision by typing the shell command alias envision.
- Within Envision you may double-click on network and then on vicinity (on the left-hand side of the split window). By doing that a specific Envision plug-in graphically displays the output of the Vicinity service registered within SeMoA's hierarchical service environment as network/vicinity.
/:1> vicinity
Printing: /network/vicinity
Name : de.fhg.igd.semoa.net.Multicastd
Info : Manages the UDP multicast socket for pingd and voted.
Author : Volker Roth
Revision: $Revision: 1.24 $/$Date: 2006-05-05 12:02:06 +0200 (Fri, 05 May 2006) $
Daemon info
-----------
Address : /239.255.18.11
Port : 40000
Requests : 101
Good : 101
Bad : 0 (0%)
Sent : 35
LAN info
---------
CN="Demo 1", OU="Users", O="SeMoA", L="Darmstadt", ST="Hessen", C="DE" (ship://169.0.0.1:55001)
Number of objects printed: 1
(4) Run the benchmark agent
- On the first machine, type alias benchagent. Be careful, input is case sensitive. The result should be: java de.fhg.igd.semoa.agent.BenchmarkAgent -rounds.
- "benchagent" is an alias that is actually interpreted as shown in the output of the "alias" command. What happens if "benchagent" is typed is that the main-method of the BenchmarkAgent class is called with the given parameter -rounds.
- Now type in: benchagent -rounds 2 -debug false. The agent should migrate to the second machine and back for the number of given rounds and produce some output on the corresponding SeMoA shells.
- The agent queries vicinity for the list of known hosts, computes a
route so that it hops once from each host to all other hosts in each round,
hops along this route, returns to its origin, and reports some statistics.
Congratulations!
You watched your first SeMoA agent in action and might want to continue with further examples, now.
|