[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] iPOPO Compatible Providers

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?