Ok - but if it is remembering....and not retrieving fresh values from the
network there must be another problem...

Because when i start the osgi framework all my upnp devices get
imported...ok consider they're now in there...


I start a upnp event listener...
Hmm lez consider that the first time all the events are delivered tot he
listener. UPnP Devices got them from the network and cache them now.
No stati changed...so upnp devices should have their old status..

Now...stop upnp event listener...
Re-register upnp event listener...


And vuala - what's happening is that some are missing...

Start / stop...others are missing otheres are there..
Start / stop...everything got delivered...

And so on...
That shouldn't happen if
--> It must therefore remember the values of the state variables of external
devices. <-- 
--> is true.


--> No when you restart the upnp event listener the UPnPDevice service
created and registered by the UPnP Base Driver (to import the UPnP
Device from the UPnP Network into the OSGi platform) should recognized
the UPnPEventListener and start to send to it the given information. So,
if you deregister and register a new UPnPEventListener it will receieve
again the initial value. This does not mean, as far as I know (you may
double check by sniffing network packet), that the UPnP Base Driver
request the data through the UPnP network. On the contrary, the
UPnPDevice service registered by the UPnP Base Driver has cached the
value since the registration of the UPnPEventListener


ok..if it remembers...then the above mentioned cannot happen..
if it does not...it can happen ok....but then there must be some code-based
safety thing for it....

if the upnp device has no valid value it should try to retrieve till it has
one...


the mighty problem is that sometimes NO values are delivered to upnp event
listeners...even if it "may" be cached?
if upnp device has cached a value...it would send the old one if it missed a
packet and not just nothing..(i dunnow if there is expiration on the
retrieved vals?)



hmm :)
well - that are my thoughts about it,

Kind regards,
Daniel



-----Ursprüngliche Nachricht-----
Von: Stefano Lenzi [mailto:[EMAIL PROTECTED] 
Gesendet: Freitag, 25. Juli 2008 18:12
An: [email protected]
Betreff: Re: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8
........m-search the problem?

Daniel Felsing wrote:
> Hmmm...
> 
> Look at osgi CMPN 111.8.1
> 
> Special care must be taken with the initial subscription to events.
> According
> to the UPnP specification, when a client subscribes for notification of
> events
> for the first time, the device sends out a number of events for each state
> variable,
> indicating the current value of each state variable. This behavior
> simplifies
> the synchronization of a device and an event-driven client.
> The UPnP Base Driver must mimic this event distribution on behalf of
> external
> devices. It must therefore remember the values of the state variables of
> external devices. A UPnP Device implementation must send out these initial
> events for each state variable they have a value for.
> The UPnP Base Driver must have stored the last event from the device and
> retransmit the value over the multicast network. The UPnP Driver must
> register
> an event listener without any filter for this purpose.
> 
> 
> --> It must therefore remember the values of the state variables of
> external devices. <--

As far as I know we do that.

> 
> 
> here lies what i mean. There must be something wrong with the remembering
> functionality.
> I restart my upnp event listener (on the server) and it should not get
every
> single event sent again over the network, but the base driver should
> remember it.

No when you restart the upnp event listener the UPnPDevice service
created and registered by the UPnP Base Driver (to import the UPnP
Device from the UPnP Network into the OSGi platform) should recognized
the UPnPEventListener and start to send to it the given information. So,
if you deregister and register a new UPnPEventListener it will receieve
again the initial value. This does not mean, as far as I know (you may
double check by sniffing network packet), that the UPnP Base Driver
request the data through the UPnP network. On the contrary, the
UPnPDevice service registered by the UPnP Base Driver has cached the
value since the registration of the UPnPEventListener

> It it is not remembering and starting for every listener an extra network
> connection, it will cause a lot of traffic.
> 
> But if it's the case that the basedriver IS remembering (i mean felix one)
> then something other must be faulty, cause everytime i restart the upnp
> tester an other
> Status is missing.

Please look at the comment above

> 
> 
> I really dunnow what to do now..
> 
> Kind regards,
> Daniel :-) 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to