UPnP/IGD implementation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

UPnP/IGD implementation

NorbertHartl
Does anyone know some code or person that did something with UPnP/IGD in pharo?

thanks,

Norbert



Reply | Threaded
Open this post in threaded view
|

Re: UPnP/IGD implementation

Sean Glazier
you should look at croquet. I believe it was in pharo and they had code to configure the router so they tunnel through. I used something similar to do port forwarding in VW so opentalk and DST could talk through a firewall and connections from the outside could be sent back etc.

 
Kind Regards,
 
Sean Glazier
 

On Mon, Jul 25, 2016 at 7:13 AM, Norbert Hartl <[hidden email]> wrote:
Does anyone know some code or person that did something with UPnP/IGD in pharo?

thanks,

Norbert




Reply | Threaded
Open this post in threaded view
|

Re: UPnP/IGD implementation

Henrik Sperre Johansen
In reply to this post by NorbertHartl

> On 25 Jul 2016, at 12:13 , Norbert Hartl <[hidden email]> 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 (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPnP/IGD implementation

NorbertHartl
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 <[hidden email]>:
>
>
>> On 25 Jul 2016, at 12:13 , Norbert Hartl <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: UPnP/IGD implementation

stepharo
In reply to this post by Sean Glazier

Croquet is GPL licensed (at least the one I checked it was). so you should pay attention because it is a viral license.


Stef


Le 25/7/16 à 16:04, Sean Glazier a écrit :
you should look at croquet. I believe it was in pharo and they had code to configure the router so they tunnel through. I used something similar to do port forwarding in VW so opentalk and DST could talk through a firewall and connections from the outside could be sent back etc.

 
Kind Regards,
 
Sean Glazier
 

On Mon, Jul 25, 2016 at 7:13 AM, Norbert Hartl <[hidden email]> wrote:
Does anyone know some code or person that did something with UPnP/IGD in pharo?

thanks,

Norbert





Reply | Threaded
Open this post in threaded view
|

Re: UPnP/IGD implementation

Henrik Sperre Johansen
In reply to this post by NorbertHartl
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 <[hidden email]> 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 <[hidden email]>:
>>
>>
>>> On 25 Jul 2016, at 12:13 , Norbert Hartl <[hidden email]> 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 (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UPnP/IGD implementation

NorbertHartl
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 <[hidden email]>:
>
> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>>
>>>> On 25 Jul 2016, at 12:13 , Norbert Hartl <[hidden email]> 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
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: UPnP/IGD implementation

Henrik Sperre Johansen
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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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 <[hidden email]> 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 <[hidden email]>:
>>>>
>>>>
>>>>> On 25 Jul 2016, at 12:13 , Norbert Hartl <[hidden email]> 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 (859 bytes) Download Attachment