Implementing Service Location Protocol
Directed Study: Networking at the Application Layer
Presented by: Lucas Stephenson
To: Richard Yu, Anthony Whitehead
For: SYSC 5906
Tuesday, September-04-12
Overview
1.
2.
3.
4.
Purpose
SLP OSS Options
OpenSLP Provisions
OpenSLP Test
•
•
•
•
•
Setup
Setup Issues
Tests
Results
Results Screenshot
5. Conclusion
2
Purpose
• Implement and verify that SLP can
• Find suitable TCP/IP network endpoints
• Unknown/Unfamiliar networks
• Any network service (novel, non-standard, uncommon, not
supported by DHCP)
• Provide rudimentary query support
• Ensure solutions are low cost
• Simple over the counter hardware
• Low development time
3
SLP OSS Options
• LiveTribe (http://livetribe.codehaus.org/LiveTribe-SLP)
• A network service management console, contains an SLP module
• Java based
• Implemented into a broader software project
• jSLP (http://jslp.sourceforge.net/)
• Java implementation of SLP
• OSGi version available
• 1 year since project activity/discussion
• OpenSLP (http://www.openslp.org/)
• C cross platform implementation
• Low activity, but some discussions
• Java version available, but at least 10 years old
4
OpenSLP Provisions
• Code libraries supporting all SLP messages
• A host service application (daemon)
• Enables SA and DA functionality
• Required for DA and scope discovery
• Not required for basic UA usage (without scopes)
• A tool that allows interaction with the local daemon to send
network messages
5
OpenSLP Test Setup
• Setup
• Consumer grade 802.11 a/b/g/n wireless router and 802.3 wired
router
• Two Windows clients
• Client machine A:
• Windows XP, wired network connection only
• Client machine B:
• Windows 7, wired (802.11n) and wireless
• OpenSLP daemon started, default configuration (SA)
6
OpenSLP Test Setup Issues
• Initially used version 1 (latest officially stable release)
• Required compilation, requiring some minimal modifications
• Had issues, (no responses from server, despite registered services)
• Tried version 2, windows binaries pre-compiled
• Issues remained
• Seemed services weren’t being registered
• Created a simple C console implementation to register services
• The application worked!
• Discovered it stopped working once application window was closed
• Local PID monitoring!
• If a local application registers a service, the service is deregistered if
the application closes
• Makes local registration using the command line useless!
7
OpenSLP Tests
• SLP allows services to be found using service types and service
types with query-able attributes.
• Tests of each both types of request were performed
• The following services were registered on machine “A”
• service:io:diop://hostname.t1.com:1337 (xChannels=5),(-xMuteable=true)
• service:io:diop://hostname.t2.com:1338 (xChannels=7),(-xMuteable=false)
• Queries were performed using both the OpenSLP slptool and a
C application using the OpenSLP Library, using the FindSrvs
method.
8
OpenSLP Results
• The services were correctly found from machine “B” as well as
from machine “A” by querying for the abstract type or abstract
and concrete types:
• “service:io” or “service:io:diop”
• Varying LDAP queries on the 2 specified attributes also
functioned, (see next slide)
9
Finding Services
10
Conclusion
• SLP protocol can locate service endpoints on an TCP/IP
network.
• Single requirement: agents representing services must be
accessible via multicast or broadcast.
• Additional platforms: due to time and unavailability of up to
date code were not able to be verified.
• Query functionality provides a powerful means to locate and
filter specific endpoints for compatible capabilities.
• However: No interaction with the endpoints are inherent and
the endpoint doesn’t necessarily exist.
11
Thanks
12