SLP-MON

A Service Location Protocol Monitor

 

Author:

Alan Q. Jamison

 

Abstract:

SLP-MON is a network monitor application used to watch the Service Location Protocol’s broadcast, request, and registration activity generated by SLP User Agents (UA), Service Agents (SA), and Directory Agents (DA).  A “listening” agent that recognizes all SLP network packets on its local network and will use a SOAP interface to send XML encoded SLP protocol activity to any configured “Listening” J2EE WEB-Service which will organize and display the network nodes and applications involved in SLP exchanges.  This is a simple management tool to get a picture of the kind of SLP load that might be occurring in the network.  The configured Web-Service could be capable of collecting and collating the SLP protocol use of numerous networks on which an SLP “Listener” was deployed.  It is kind of a “Where’s Waldo” map!

 

What:

            What it will do:

A Java based SLP class package written by Alan Q. Jamison will be used to create the SLP “Listener”.  It will “Listen” as a DA so that it can recognize UA and SA requests for Directory Services (which is the first required check by the SLP protocol), but it will not respond, nor will it be able to detect the answer from a REAL DA in response to a multicast SA or UA request, only that a Directory Service request was seen from a UA or SA.  This Listener may be able to query DA’s after the fact to see what kind of SA or UA successfully registered for service in a known DA.

 

The SLP “Listener” will package the request up into an XML packet, and using the SOAP interface to the SLP Web server, will route the SLP protocol event to the SLP Web server for display in its SLP admin screen and possible logging.

 

Features:  The SLP Listener

1.      Ability to listen for SLP protocol multicast requests and advertisements using the SLP Java class library written by Alan Q. Jamison.

2.      A SOAP interface to a remote SLP WEB-Service.

3.      Ability to transform an SLP protocol event into and XML format suitable for the WEB-Server to process off its SOAP interface.

4.      It MAY be implemented to query known DA’s for successful registration requests resulting from the service request or query of a UA or SA, and to send that information back in XML form to the SLP WEB-Service.

5.      It MAY implement a WEB-Service call-back or SOAP API that will allow the SLP WEB-Service to shut it down, reset, or disable reporting.

 

Features:  The SLP WEB-Service

1.      A J2EE, XML based servlet application.

2.      Provides a SOAP interface to accept SLP-Listener events in XML format.

3.      Implements an SLP-Display servlet that can transform its SLP-Listener XML data into a suitable output format for display and analysis.

4.      It MAY  implement an administration servlet to shutdown a reporting SLP-Listener, disable its reporting, or clear the SLP-Listener’s reporting state (a Listen refresh).

5.      It MAY display an SVG graph of the nodes running SLP applications and the details of each SLP application’s registration information (this done by clicking on the node in the SVG graph).

6.      I am currently limiting the J2EE implementation to using XML/XSL, servlets, HTML and/or SVG.

 

Execution and configuration:

1.      The SLP Web-Service will be configured and run very much like Project 3 or 4.  I will use the same organization as these projects.  Tomcat and the existing cscie-259 J2EE library configuration is the foundational platform for this Web-Server.

2.      The SLP-Listener will require only a J2SE environment and the appropriate WEB-Service SOAP/AXIS modules to run on any network whose SLP activity is to be monitored.  The listener will be configured with XML configuration files, and the location of the WEB-Service will likely be hard coded into this XML configuration file.  The idea is that the SLP-Listener be as easy to deploy as possible on any network capable of running the standard J2SE and any necessary SOAP libraries. (See Questions).

 

Why:

The Harvard network has a great amount of SLP protocol running through it.  Since it is a first, a location protocol implemented with recurring multi-cast UDP or TCP packets, it might be beneficial to monitor the real load on the network of this protocol.  It might also help network administrators target and re-deploy certain SLP based applications to quieter network segments, or remove unnecessary or redundant SLP agents altogether.

 

This is really fascinating to me.  When I first implemented the SLP class library for a home grown UDP based peer-to-peer Instant Messenger application, I was *Shocked* to see all the SLP packet protocol running on the Harvard networks.  I saw only a little of the types of SLP agents being used, what their names were, where they were running, and what other SLP Directory agents were in use.  There is a ton of information that one can glean from a chatty SLP advertisement or request.  I want to see how common or “bad” it gets.

 

If I can make an SLP-Listener capable of running on one network and still talk to my SLP-WEB-Service on another network, it could be just fascinating to see how this protocol is being used and how wide-spread it use.

 

How:

Infrastructure:

1.      Expected to run on nice with the cscie-259 infrastructure.

2.      There may be an interest in configuring a node outside the nice net-segment where I can run and test inter-net communication between network segments.  (ie. one of the church street lab/network segments).

3.      The project will be implemented using Java.

 

XML-Technologies to Employ:

1.      XML/XSL

2.      SVG possibly for network graph display

3.      XHTML

4.      J2EE servlets and AXIS/SOAP

 

New skills to be acquired and Research to be done:

1.      SOAP

2.      WSDL usage for the SLP-Listener to get to my internet WEB-Server.

3.      Client side SOAP.

4.      More SVG and XHTML content creation – you know, the kind that looks like someone who knew what they were doing produces!!  This is a stretch for me though!!  I’ll be happy to see some recognizable information!

5.      Server side SOAP under J2EE.

Questions:

1.      What is the configuration requirement for a java network client to use a SOAP interface to a WEB service on the internet?

2.      Can I expect to do this between the Harvard nets with my web-service running on nice?  This would be very cool.

3.      I wrote the SLP class library for another project.  I simply want to re-use it for the runtime capability that enables the data collection process for this SLP-Web service.  I do not consider this smaller component a re-submission, but I want to ask if any would?