Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] iPOPO Compatible Providers
Hi Markus,

I played a little with Zeroconf, and I'm able to send notifications (except updates).
It's still a work in progress, e.g. it doesn't registers the detected services.
The code is on GitHub [1], for more visibility.

It seems that the ECF mDNS discovery uses Java serialization, which is unreadable for Python, to transfer non-String objects in service properties.
The current version of the Python implementation uses the JSON format for common types (lists of strings, dictionaries, etc).

[1] https://github.com/tcalmant/pelix-ecf-chat/blob/master/experiment/mdnssd.py

Cheers,
Thomas



2013/11/20 Thomas Calmant <thomas.calmant@xxxxxxxxx>
I overlooked it when I started the iPOPO remote services (1 year ago), but I didn't found an easy way to notify services properties changes (only addition and removal).
I don't know if I missed it or if it is the way the protocol works.

I still haven't looked at the org.eclipse.ecf.provider.jmdns bundle, I planned to try to mimic its behavior with pyzeroconf.
An early draft is available on my dropbox [1].

[1] https://www.dropbox.com/s/3d8dcuva4y91dil/mdnssd.py

Thomas


2013/11/20 Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>
On 11/20/2013 01:52 AM, Thomas Calmant wrote:
> 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).


What about re-using an existing multicast-based solution like pyzeroconf
[1]?

M

[1] https://github.com/mcfletch/pyzeroconf
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev


Back to the top