[SeMoA Logo Strip] [SeMoA Logo Strip] [SeMoA Logo Strip]
 About  -  Documentation  -  Download  -  Misc 

(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.

     > Type 'info' to get some initial help. <

    /:0> why
    No stack trace.

(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://
    Enabled  : true
    Capacity : 1
    Max size : 64535
    Requests : 0
    Good     : 0
    Bad      : 0 (0%)
    comm.pod.acl --> FIPA ACL
    comm.pod.url --> pod://
    comm.pods.acl --> FIPA ACL
    comm.pods.url --> pods://
    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 -->
    network.httpsd.url -->
    network.rshd.url -->
    network.sshd.url --> ssh://
    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://
    transport.in.raws.max --> 262144
    transport.in.raws.url --> raws://
    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  : /
    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://
    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.


You watched your first SeMoA agent in action and might want to continue with further examples, now.