Plugin developers: Use of UPNP in your plugins?

Hi everyone.

In another thread discussion turned to UPNP discovery of devices on the network.

The Amazon Echo scripts that folk had used were failing when any other UPNP software was running, including plugins such as Sonos. I experienced this myself last year when writing the unpublished plugin SkyRemote, for UK Sky TV users.

I proposed last year, and again in this thread, the idea of a UPNP broker in Indigo that allowed plugin authors to subscribe to UPNP broadcast alerts when they required them, and be notified of any received that matched their required data.

Jay currently thinks there's not enough demand for it, but I suspect with the number of AV/TV based plugins that are available and growing, there may be others that haven't come to light.

Could you respond to the poll and this thread with your thoughts - I've allowed two responses per user so you can tick option 4 if you want it, alongside options 1-3.

If there is demand (both now and growing into the future) then maybe Jay can get this built into Indigo 7 before its released.**

**Jay, I'm kidding!

I'm currently aware of:

Sonos
Amazon Echo
SkyRemote

Are there others? (I guess Bonjour could be built into this as well, unless Bonjour doesn't bind to a port and hold it open?)

Peter

[jay (support)]

This doesn't apply to bonjour (at least I'm pretty sure it doesn't).

Howard:

Just to be clear, you are talking here about advertising services via UPnP, so this really is only useful for those applications that need to tell other hardware that Indigo will be acting as a service. It does not apply to those which are simply doing a UPnP search for devices (as this will not bind and keep the port open for extended times like advertising does.) Nearly all of my A/V plugins use UPnP to discover devices on the network on the device configuration dialog screens.

Adam

Hi Adam,

No, I'm talking about UPNP searching/listening.

At least I was, until you posted.

Is that the problem with the Sonos plugin? Is that advertising permanently, which is why none of us can do UPNP listening whilst that plugin is running?

I was hoping you'd respond to this thread because I suspected many of your plugins would do UPNP search to find the devices - which you can't do if the port is bound by another plugin/app?

UK Sky TV boxes only advertise UPNP once every x minutes (I seem to think it was 5, though that does seem excessive when their app finds the box quicker than that) so I have to bind to the port for a length of time watching for advertisements.

My idea is indigo binds to the port whenever any plugin needs to listen, and passes any incoming advert to any plugin that is currently subscribed to UPNP alerts. When no plugins are currently subscribed, Indigo doesn't bind.

If advertising is the issue, then presumably indigo could handle this as well - have indigo do the advertising for plugins, with the data and frequency defined in the function call to indigo. Indigo then binds to UPNP every 'frequency' minutes/seconds to broadcast 'data' then unbinds. Listening happens the same as above.

Does this make more sense?

Peter


Sent from my iPhone using Tapatalk

Yeah, the majority of my plugins use a UPnP search to find their devices -- but as the client you initiate a response from those devices which are listening / advertising their services. SO, the client (here my plugins but obviously can be any app) will execute a UDP broadcast that they are interested in consuming some services. There are some filters and such that you can add to the request so that (hopefully) only those you need will be returned. The client needs only listen for a short time to get the responses, then closes all network communication... a couple of seconds. This only needs to be done when you are actively searching for new services to use.

The problem is that if you want to RESPOND to other clients initiating that broadcast as described, you must continuously listen on port 1900 for those requests. Multiple applications which are binding to that port in order to respond are what are locking you up.

SO, I think the number of plugins advertising services for others is pretty small. As you have seen with a few other devices, some require you put them in listen mode so that they will bind to the port and respond, becoming "discoverable" in a bluetooth-like sense. I guess if a client were continuously searching you could lock up some ports as well, so that is why it should only be done when new services are needed... a settings screen, a dialog, etc. Best behavior for any application/plugin in a shared environment would be to only do that when the user requests it (and then maybe a set amount of time or while a dialog is up or whatever).

This is somewhat of a simplification - there are more nuances, such as some devices have a Cache time and they won't respond again to the same host for that certain amount of cache time (and it tells you that in the initial return.) Other gotchas, but those are the basics as I know them. I'm not an expert on it by ANY means, just had to research it and view a few WireShark examples to implement a UPnP Python class or two for the plugins.

I have to agree with Jay that an Indigo-provided solution is unnecessary and not worth the effort on this one. A good idea, but other ideas (to me) would be far higher priority.

I've been silently reading input here as the Sonos plugin has been mentioned as a port hog. As an FYI - and hopefully of help to a few, I am integrating a new event processor that will not keep the UPNP discovery port open. It will explicitly create subscriptions as needed for device updates. I'm probably a couple of weeks out from a release, but wanted to let everyone know.

-Nick

Cool, thanks Nick.


Sent from my iPhone using Tapatalk

The problem is that if you want to RESPOND to other clients initiating that broadcast as described, you must continuously listen on port 1900 for those requests. Multiple applications which are binding to that port in order to respond are what are locking you up.

This really shouldn't be a problem. As long as the listeners set the SO_REUSEPORT socket option, they can all listen and all receive multicast packets - the OS is happy to distribute multicast packets to all comers (kind of makes sense for broadcast/multicast).

Trivial code to listen for SSDP announcements, cooperatively:

Code: Select all

#!/usr/bin/python
import socket
import struct

def main():
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
    s.bind(('', 1900))
    mreq = struct.pack("=4sl", socket.inet_aton('239.255.255.250'), socket.INADDR_ANY)
    s.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)

    while True:
        packet, packetaddr = s.recvfrom(65536)
        print "Received packet from %s" % (packetaddr,)
        print packet

if __name__ == "__main__":
    main()


This really shouldn't be a problem. As long as the listeners set the SO_REUSEPORT socket option, they can all listen and all receive multicast packets - the OS is happy to distribute multicast packets to all comers (kind of makes sense for broadcast/multicast).

But this only works if all listeners are open it shared, right? Which for plugins may not be an issue since they may be modified, but other (compiled) programs could still give issues. Though obviously best to make what we can act properly, which seems to be the way you are headed.

I wonder what happens if one or more plugins are listening and another application requests exclusive access - does their bind fail? it automatically revert to reusable?

[jay (support)]

The 1.0.2 release of the Alexa Hue bridge plugin uses this technique. I tried it along with John Ray's script which I modified to also use SO_REUSEPORT and they both worked together correctly, so I'm hopeful that it will work for other scenarios also. I don't know what would happen if there were another process that opened the port without it, I'll leave that to someone else to experiment with.