You don't use SSDP to do the tweaking, but to discover the devices that are available to tweak. Tweaking is subsequently carried out using SOAP/XML. An an uninformed guess, I'd imagine use could look a bit like this: SSDPClient when: IGDServiceAvailable do: [:IGDService | IGDConfigurator configure: IGDService to: [:configurator | configurator ppp natEnabled: true; addPortMapping: srcPort to: dstPort on: targetMachine ] Where IGDConfigurator / ppp is the missing piece, building/sending SOAP messages* to the provided service, corresponding to http://upnp.org/specs/gw/UPnP-gw-WANPPPConnection-v1-Service.pdf Cheers, Henry * the core (messaging parts of http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf) of which can probably be abstracted into a UPnPConfigurator, so all you do in IGD is link the API to which fields to send in the soap messages
On 26 Jul 2016, at 4:19 , Norbert Hartl <norbert@hartl.name> wrote:
Thanks,
I think I need to read a bit further in order to understand how it works really. Didn't know SSDP ist used when tweaking things with IGD.
Norbert
Am 25.07.2016 um 17:01 schrieb Henrik Johansen <henrik.s.johansen@veloxit.no>:
SSDP covers discovery of the services and how they are set up; SOAP and XML are then used to access the service. IANAE, but; I think as long as you restrict yourself to implement use of the particular service (IGD) you are interested in, it shouldn't be all that bad; the use of SSDP discovery data should be fairly straigh forward the way its modelled; you provide the client with callbacks that run when a service of the type you've specified you're interested in becomes available/unavailable.
The main problem with UPnP (well, other than accessing services involving SOAP and XML instead of REST) is its size; a callback handling "IGD service discovered" should be much simpler than if one wanted to handle "UPnP device discovered" (or, if that's the pattern, restricting UPnP device discovery handling to check if IGD is available).
(You might want a separate Service subclass to ease access / document what the different fields are though, IIRC, the current Service follows the MorphicExtension pattern of putting anything that does not have a well-defined meaning in SSDP in a dictionary)
Cheers, Henry
On 25 Jul 2016, at 3:29 , Norbert Hartl <norbert@hartl.name> wrote:
Thanks,
am I wrong in assuming the UPnP and IGD are rather huge and complicated things to implement? I just want to figure out if there is a clear answer to the question if implementing a subset or using a library (mini upnp) through FFI is more feasible.
Norbert
Am 25.07.2016 um 16:10 schrieb Henrik Johansen <henrik.s.johansen@veloxit.no>:
On 25 Jul 2016, at 12:13 , Norbert Hartl <norbert@hartl.name> wrote:
Does anyone know some code or person that did something with UPnP/IGD in pharo?
thanks,
Norbert
I've done an SSDP client/server, but not gone so far as to build a full UPnP model on top of it, since I just needed a discovery protocol. http://smalltalkhub.com/#!/~henriksp/SSDP.
Should be possible to use as a base though; you can make a client with type ssdp:all, and get some fun replies indicating the services available on UPnP routers.
Caveats apply to the socket init code which is really ugly, it attempts to listen on all the interfaces present at the time of client creation, but the correct primitives aren't really exposed from the plugin, the results can be a bit hit and miss depending on OS/Distribution; nor are there hooks to get notified when interfaces go up/down, so accounting for such currently comes down to manual resets.
Cheers, Henry