Re: [ecf-dev] iPOPO Compatible Providers

[Thomas Calmant <thomas.calmant@xxxxxxxxx>]

Hi,

I got a case where services had serveral, very long properties values (full text strings), which implied to send packets larger than 1600 bytes on notifications (registration and update).

Of course, it raised the UDP packet ordering problem, so I decided to use multicast for small event packets only, and HTTP for information transfer.

This is one implementation of a discovery protocol: other implementations can ignore the dispatcher servlet.

Also, in this case, the HTTP server must be active for JSON-RPC to work, so there were no real constraint against this servlet.

New providers can work without the dispatcher servlet without problem, as long as we have this "horror case" (the problematic exported service has been cleaned up since).

++

Thomas

2013/11/19 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.

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev