Re: [ecf-dev] iPOPO Compatible Providers

[Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>]

On 11/19/2013 02:43 PM, Thomas Calmant wrote:
> 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.
> 

Hi Thomas,

it sounds a little bit heavy-weight if the discovery client (discoverer)
has to run an http server instance. Why do you have to transfer large
dictionaries in the first place? Do you have an example?

Thanks
M.