Nested ServiceList not handled by sample app?

zephyrus
2009-08-11
2012-12-14
  • zephyrus

    zephyrus - 2009-08-11

    Hi,

    I downloaded libupnp-1.6.6 while ago to see if I can emulate
    an IGD on top of router that doesn't have UPnP on its own.
    (It is like having a linux IGD on top of a linux system used as router. It is just that
    in my case, the IGD-like daemon runs on a PC and a router is separate entity. It should be doable, I hope. (I intend to control the router via its console line or logging into it using
    old-fashioned telnet. Even it turns impossible, it is interesting to learn how UPnP works under the desk so to speak.)

    Anyway, I have downloaded document from upnp forum, which recently seems to have
    merged with another organization. Anyway, in its document (a whole bunch is available
    as one zip file), there are sample xml description of IGD device which I
    copied and modified to create a sample IGD description.
    See the original
    http://www.upnp.org/standardizeddcps/default.asp
    -  Single Download File for UPnP™ Documents
    and
    - Networking Internet Gateway:1

    One problem I encountered is that IGD device consists of a few device
    internally actually, and its description is very hierarchical unlike the simple
    sample tv device and its controller in libupnp sample directory.

    Its xml description has nested description.
    root device -> list of service, another device ->  another servicelist, etc.

    To my surprise, when I tried to modify the the sample application to create
    a sample device based on my xml description of IDG device, I found that
    sample will never work if we use SampleUtil_* routines.
    This is because the nested servicelist (at the second level, etc..) is not found
    by the  mimicked/modfiied  tvDeviceStateTableInit (), which  calls

    SampleUtil_FindAndParseService (), but it in turn calls

    SampleUtil_GetFirstServiceList( ) and as the name suggests
    it only picks up the first list at the top-level and
    never bother to try to see the servicelist of the nested Devices, for example.

    As a result, for testing purposes, I had to flatten my xml description
    by removing the nested root to create a very simplified (and yet maybe not
    quite correct) IDG that has all the services in one flattened list at the top level.

    Now, at least my program begin working.

    Am I doing something incorrect?

    Or is the SampleUtil_* functions meant to show
    the handling in the simplistic cases and
    never intended to handle complex device with nested devices and
    services like real-world IDG?

    It is a pity that a sample XML description (after suitably modifed
    by inserting appropriate strings) in IDG document from UPNP
    can not work with libupnp.

    Any helpful tips to work with the XML sample from UPnP forum
    will be appreciated.

    (I had found a very simple generator program to produce a code snippet that handles
    the setting of state variables and handles actions (obtaining input parameter values
    and setting output values), etc. and
    can be used with libupnp from a given xml description. But that
    simple generator only works with simple xml descriptions of tv device and
    didn't work with IDG sample xml description from UPnP.
    When this generator didn't work, I looked into the code and realized
    this nested device, servicelist problems. I wonder how others coop with
    complex xml construct.

    TIA

     
    • zephyrus

      zephyrus - 2009-08-13

      I did the following to fix the particular problem and it looks promizing.

      I changed sample_util.c so that the serviceList is searched
      until the desired service is found instead of just looking at
      the first servicelist of the root device.

      With the change, I could make a modified control point program (based on
      upnp_*_ctrl) to understand the full xml description based on IDG spec from UPnP Forum.

      Obviusly, the full-spec XML (not the flattened version) is required for IDG-compatibility
      and before, portmapper-1.6.jar (a program to control portmapping available from
      sourceforge.net:search upnp portmapping)
      could not find the simulated IGD device, but with the
      modification above and the full XML description, portmapper now
      recognizes the IGD device again based on heavily modified
      upnp_tvdevice source.

      So a great progress.

      I am going to post a patch for sample_util.c
      The patch contains a few indentation changes, addition of
      error message string (on top of the integer error code), etc in other places.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks