Hi Markus,
I only have support for multicast discovery right now.
I'll work again on the project on Thursday, I was planning to write adapters my current Java implementation and ECF, but we can discuss on what to do before.
There is no clear explanation on how the discovery protocol works (yeah, something more to add to my TODO list ^^), but here is how Pelix remote services works :
First, there is a "dispatcher servlet" which is bound to an HTTP service, and returns complete information about exported services (UID, endpoint name, properties, ...)
The multicast discovery is notified by the "dispatcher core" of changes in exported services: endpoint added, updated and removed.
Multicast packets are small JSON objects, with the following keys:
- "path": URI to the dispatcher servlet, "/pelix-dispatcher" by default
- "port": Port to the HTTP server hosting the servlet (the IP is the one used to send the multicast packet)
- "sender": UUID of the framework that sent the request
- "uid": UUID of the endpoint this event is about (optional)
- "event": kind of event, one of
* "discovery": the sender wants to know who's there, the answer is a POST request to the dispatcher servlet by each receiver.
The POST body contains the services exported by the one who received the "discovery" packet.
* "add": a new endpoint is available, the "uid" field indicates which one, the servlet can be used to retrieve its information
* "update": endpoint update, "uid" given in fields
* "remove endpoint removed, "uid" given in fields
This multicast-servlet couple has been decided because of packet fragmentation : sending service properties (which can be a very large dictionary) can lead to reception problems due to the underlying UDP constraints.
Cheers,
Thomas
