Implementing Service Location Protocol

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

2. Overview • Purpose • SLP OSS Options • OpenSLPProvisions • OpenSLP Test • Setup • Setup Issues • Tests • Results • Results Screenshot • Conclusion

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

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

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

6. 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)

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

8. 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 OpenSLPslptool and a C application using the OpenSLP Library, using the FindSrvsmethod.

9. 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)

10. Finding Services

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

12. Thanks