How To...Agent-to-Agent networking/messaging

This article describes how to get one Wolfpack instance sending notification messages to another instance - eg: a distributed monitoring scenario.

Quick Start

  1. Install a Wolfpack instance on the "client" pc/server to be monitored (sender). (tip: chocolately install with "cinst wolfpack"). This instance will generate notifications.
  2. Install a Wolfpack instance on the "server" pc/server (receiver).
  3. Start both instances
  4. On the "client" instance go to the configuration UI page (http://localhost:802/ui/configure) and locate the "WebServicePublisher" plugin (under WebService tag) and click "Create".
    1. Update the BaseUrl property to the ipaddress/machine name of the server/receiver instance (remember to use double quotes around the value)
    2. Set ApiKey to blank (security is explained later)
    3. Change FriendlyId to something like descriptive like "BuildServerWolfpackPublisher"
    4. Enabled should be true
  5. Restart the client instance to pick up the configuration change
  6. The server/receiver instance is enabled by default to receive messages via the Notify Api method
    1. The default filesystem notification repository will be in operation - notifications will be stored as json format files in the wolfpack install folder\_notifications folder.
      1. You can change the default repository by configuring the Sql or MongoDb publisher (plus any other publisher that acts as a NotificationRepository).
  7. Any notification generated on the client should now be sent to the server instance and rebroadcast to all enabled publishers.
  8. Add more client instances as required.

Details

interagent_wolfpackv3.png
The basic communication pattern is based on a "store & forward" principle which makes the client tolerate a dropped/intermittent connection between the two agents. As the connection is http based it can also be secured at the transport layer with SSL and logically with an API Key unique to each client.
  1. As a notification is generated on the client it is stored in the default notification repository (filesystem/json files). A background process executes every 10 seconds (configurable) to grab these queued notifications and attempt to send them to the receiving instance, this logic is wrapped up in a "strategy" component. If the notification cannot be sent it remains queued and will be resent in the next pass.
  2. The actual mechanism to send the message is a simple POST api call
  3. The "strategy" at the server/receiver instance will validate the notification to ensure it is not stale (too old) or a duplicate - if valid it will republish the notification to the internal message bus just as if it was generated locally.






Last edited Jul 15, 2014 at 1:31 PM by jimbobdog, version 7