Oddly specific requests for integration in pyatv

[postlund]

I'm finally looking at what it would take to migrate pyatv back to python-zeroconf. Most of the things have already been added before (thanks!), but I have some additional things to address.

One thing I'm doing as an optimization is to request several services in the same request (which python-zeroconf supports). This used to make things simple as I would send one request, get one response and now that I was done. During the summer I added a few new services, which led to an interesting problem: the response got too big to fit all records so the target device would drop some of them (seemingly random), making the responses incomplete. I "fixed" this by splitting the services over a few requests (four services per request I think) and await the responses. In my own code I count the number of responses and compare with sent requests, thus knowing if I have received all responses or not. No response will be sent in case none of the services are announced by a device (naturally) so I am including a "dummy" service (in all requests) that I know most Apple devices support, thus yielding a pretty good chance of getting a response to all my requests. The entire optimization would fall in case a single request would not yield a response.

This is an optimization as I don't have to wait a fixed time when scanning for a device, thus exiting early is possible. Can something similar be implemented here? As I have no idea knowing what services a device might have, it's not possible to just look at the service types.

Another thing I have support for is detecting if a device is sleeping. When (an Apple) device goes to deep sleep, it "hands over" the zeroconf services to a sleep proxy on the network. The sleep proxy will invalidate the MAC address of said device and start announcing the services on-behalf of the sleeping device. Whenever someone makes a request to one of the services, the sleep proxy will wake the device (WoL), again invalidate the MAC address and target device will eventually take over the services again. I observed a pattern here: sleep proxies only include PTR records to the services (postlund/pyatv#717 (comment)), the client must thus request them manually. I kind of made the naive assumption that if the port of all services is 0, then it originated from a sleep proxy and the device must be asleep. Would this also be possible to detect somehow?

I know I'm doing some really strange things... 😉

[bdraco]

In case you haven't seen this

http://stuartcheshire.org/SleepProxy/index.html

[bdraco]

One thing I'm doing as an optimization is to request several services in the same request (which python-zeroconf supports). This used to make things simple as I would send one request, get one response and now that I was done. During the summer I added a few new services, which led to an interesting problem: the response got too big to fit all records so the target device would drop some of them (seemingly random), making the responses incomplete. I "fixed" this by splitting the services over a few requests (four services per request I think) and await the responses. In my own code I count the number of responses and compare with sent requests, thus knowing if I have received all responses or not. No response will be sent in case none of the services are announced by a device (naturally) so I am including a "dummy" service (in all requests) that I know most Apple devices support, thus yielding a pretty good chance of getting a response to all my requests. The entire optimization would fall in case a single request would not yield a response.

Can you provide some more detail on what you are requesting or point me at the request code?

[bdraco]

pyatv is using zeroconf discovery now, closing this