Difference between revisions of "DNS-SD based wide-area ECF discovery provider"
(New page: Project Lead: Markus Alexander Kuppe (IRC: lemmy) Mentor: Scott Lewis This project is part of the Google Summer of Code 2010 ==Abstract== ECF has been supporting multicast based dis...)
|Line 73:||Line 73:|
=== Open issues ===
=== Open issues ===
=== New ideas ===
=== New ideas ===
Revision as of 04:44, 27 April 2010
Project Lead: Markus Alexander Kuppe (IRC: lemmy)
Mentor: Scott Lewis
This project is part of the Google Summer of Code 2010
ECF has been supporting multicast based discovery for a while now allowing for zero configuration remote services or any other service discovery and advertisement. However, multicast discovery is limited to the local subnet only. Thus it's time to bring discovery to wide area networks (WAN) by implementing functionality for DNS-SD based discovery which will enable a complete new range of use cases.
DNS-SD (re)uses regular DNS (a dedicated directory) or more precisely SRV, TXT and PTR records as described in RFC 2782, RFC 1035 to find and advertise services in the global domain name system. With DNS-SD it is possible to publish any kind of service including parameters by predefined service types (RFC 2782). For more background information on DNS-SD check out the slideware that I used during the ECF tutorial at EclipseCon2009  or see http://www.dns-sd.org/.
A use cases that quickly comes to mind, is to advertise Eclipse update sites/p2 repositories via this ECF discovery provider so that you never ever have to manually add the URL of e.g. the next release train to the p2 director again . It only requires the webmasters to add a couple of records to the "eclipse.org" domain. But it can even go further when services are automatically advertised and added to the zones via DNS dynamic update. And scalability would not even be a matter due to DNS' efficient caching. All in all any distributed project in Eclipse land will benefit from this enhancement and is likely to become a consumer of ECF wide area discovery.
Therefore the existing ECF mDNS provider  should be extended or a new provider created which leverage a (EPLed) DNS resolver as well as support for DNS update (RFC 2136) to provide both service discovery and service announcement. Alternatively the existing SLP provider can be supplemented with DNS SRV functionality as described in RFC 3832.
-  http://ecf2.osuosl.org/Distributed_OSGi_-_The_ECF_way_rev02.pdf p. 64ff
-  https://bugs.eclipse.org/bugs/show_bug.cgi?id=218534
-  https://bugs.eclipse.org/bugs/show_bug.cgi?id=258340
-  http://wiki.eclipse.org/ECF_API_Docs#Discovery_API
Ping me on IRC (lemmy) or Jabber/mail (firstname @ lastname.org) for details, question, comments or criticism. :-)
- Feature complete DNS-SD based ECF discovery provider
- Service discovery
- Service advertisement
- Tests for the ECF discovery "TCK"
- Licensed under EPL
- Integration into ECF build/p2 repository
- Ready to be shipped with next ECF release
Here is a complete list of the milestones and release candidates planned for this plugin.
|M1||Week 1-3||Research, Requirements gathering|
|M2||Week 4-6||Impl of (standalone) DNS resolver, DNS update (rfc2136). Alternatively reuse of dnsjava  incl. CQ and upstream OSGi-fication or Orbit|
|M3||Week 7-9||DNS-SD ECF discovery provider implementation, unit tests|
|M4||Week 10-12||Documentation, General requirements and design specifications, Lessons learned|
Getting the source
The code will be available from the regular ECF repo at dev.eclipse.org. Parts of it might have to go to the ECF OSU repo first due to licensing.
Check https://bugs.eclipse.org/310580 for progress
Do you have a great idea for this project? Just open a new feature request.