Agreeing with Nektarios and because of the confusion the specification
sometimes causes I have one practical question: Where and how does the bug
described below cause any problems?
> --- Ursprüngliche Nachricht ---
> Von: "Nektarios K. Papadopoulos" <npapadop@xxxxxxxxxxxxxxxxxxxx>
> An: UPnP-SDK-discuss@xxxxxxxxxxxxxxxxxxxxx
> Betreff: Re: [UPnP-SDK-discuss] Bug in sending advertisment set
> Datum: Fri, 05 May 2006 11:06:59 +0300
>
> I've always found it hard to be absolutely sure what the UPnP Device
> Architecture specifies :-P
>
> Having said that, let me point to two other quotes from the same section:
>
> "Due to the unreliable nature of UDP, devices should send each of the
> above discovery messages more than once."
>
> "These messages must be sent out as a series with roughly comparable
> expiration times; order is unimportant, but refreshing or canceling
> individual messages is prohibited."
>
> I guess the first quote lead the original author to this implementation.
> The second is really confusing for me. How can one *refresh* or *cancel*
> an individual message ?
>
> Triggered by *"sent out as a series"*, I came up with the attached
> patch. Sending NUM_COPY times the *series* of the messages ;-)
>
> What do others think?
>
> PS: BTW, did these duplicate messages confused your control point ? I've
> never had any problem with the multiple NOTIFY messages.
>
> Olga Soiko wrote:
> > According to UPnP Device Architecture
> > Section 1.1.2 Discovery: Advertisement: Device available -- NOTIFY
> > with ssdp:alive
> > "NT" in NOTIFY message described the next:
> >
> > NT
> > Required header defined by GENA. Notification Type.
> > Must be one of the following. (cf. table above.)
> > Single URI.
> > upnp:rootdevice
> > Sent once for root device.
> > uuid:device-UUID
> > Sent once for each device, root or embedded.
> > Device UUID specified by UPnP vendor.
> > urn:schemas-upnp-org:device:deviceType:v
> > Sent once for each device, root or embedded.
> > Device type and version defined by UPnP Forum working
> > committee.
> > urn:schemas-upnp-org:service:serviceType:v
> > Sent once for each service.
> > Service type and version defined by UPnP Forum working
> > committee.
> >
> > Because of 'while(NUM_COPY)' in the function 'NewRequestHandler'
> > NOTIFY messages with the same values of 'upnp:rootdevice',
> > 'uuid:device-UUID', 'urn:schemas-upnp-org:device:deviceType:v',
> > 'urn:schemas-upnp-org:service:serviceType:v' are sent more than ones.
> > I propose to delete 'while'.
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > diff -Naur old/upnp/src/ssdp/ssdp_device.c
> new/upnp/src/ssdp/ssdp_device.c
> > --- old/upnp/src/ssdp/ssdp_device.c 2006-02-22 23:38:04 +0200
> > +++ new/upnp/src/ssdp/ssdp_device.c 2006-04-10 16:50:43 +0300
> > @@ -231,7 +231,7 @@
> > int rc;
> >
> > NumCopy = 0;
> > - while( NumCopy < NUM_COPY ) {
> > +// while( NumCopy < NUM_COPY ) {
> > DBGONLY( UpnpPrintf( UPNP_INFO, SSDP, __FILE__, __LINE__,
> > ">>> SSDP SEND >>>\n%s\n",
> > *( RqPacket + Index ) );
> > @@ -241,7 +241,7 @@
> > 0, ( struct sockaddr * )DestAddr, socklen
> );
> > imillisleep( SSDP_PAUSE );
> > ++NumCopy;
> > - }
> > +// }
> > }
> >
> > shutdown( ReplySock, SD_BOTH );
>
> --
> ______________________________________________________________
> Nektarios K. Papadopoulos
> Senior Engineer
> Software Engineering Group
> inAccess Networks
> 95A Pentelis Avenue. Tel : +30-210-6837640
> 152 34 Halandri Athens Fax : +30-210-6899504
> ______________________________________________________________
>
--
Analog-/ISDN-Nutzer sparen mit GMX SmartSurfer bis zu 70%!
Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
|
