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 <norb...@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.johan...@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 <norb...@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.johan...@veloxit.no>:
>>>>
>>>>
>>>>> On 25 Jul 2016, at 12:13 , Norbert Hartl <norb...@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
>>>
>>>
>>
>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
