Hiho, hm... but the only thing the workaround fixes is when the server is already running and after that i start the host that is exporting the devies with e.g. 500ms delay.
But in fact it can be vice versa. The host is already running, or the server is. The fix doesnt change anything by the way :( i just tried it out. My workaround is right now - when refining driver is registering the new "wrapping obj" for upnpdevice it gets the initial values by action.invoke.. then i send the msg on the internal event bus (event admin) - the upnp eventing on status change ( so not the initial upnpeventnotify thing ) works ok for me so far. The only thing interesting ist he following: I have the possibility to create a new device on my upnp exporter host....ok consider 17 devices are already exported..and i register an 18th device ...my server finds the device ...but i can start to use it (so switching it results in upnpnotify) about ~30secs-1 minute later?... Is this behavior ok? Francesco.. What do you think about what i described in the previous mail?... ==> http://www.mail-archive.com/[email protected]/msg01781.html please take a look at it :) Kind regards, Daniel -----Ursprüngliche Nachricht----- Von: Francesco Furfari [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 25. Juli 2008 20:28 An: [email protected] Betreff: Re: AW: AW: AW: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8 ........m-search the problem? AH ... one more note... Hi Daniel, I quickly read the thread because I'm back just now. Unfortunately the Notify callback is over TCP, so unless we have a similar problem even with TCP communication, the topics you discussed should not be applicable in your case. Nevertheless we can always have a problem with the messages buffering or multi-threading. As workaround I suggest to insert in your bridge code a wait (e.g. 500 ms) just after registering the UPnP service with the framework. let us know if it works. francesco Daniel Felsing wrote: >> UPnP event are meant to be best-effort because they are meant to be >> non-critical information which if lost will be received in the next >> changing of the value or anytime the device decide to send the event. > > ok...but 17 devices aren't that much...consider you export 100..200 > maybe it's a solution to retrieve the upd packets from the nic in an own > worker process (so the packets do not get dropped) > and then processed... > > i'm sitting in a lan with 1000mbit direct connection and 2x1m cables :/ > best-effort ok..but no other traffic is handled except as my 2 workstations > (one a e8400 and second computer a T7200 notebook..) > >> We probably should try to updated the CyberDomo and the CyberLink stack >> in way to make it more Thread, but we also keep in consideration power >> constraint device, because our goal is to make the UPnP Base Driver run >> either on JDK1.3 and embedded system > > I'm not 100% sure if it's really the cyberdomo stack...the problem could be > on basedriver or cyberdomo. > But the thing that the "caching" on importers side doesn't seem to work (see > my other post) there may also > be a problem on the basedrivers'side > > >> Up to now we have neglected to fix the CyberDomo with the patch propose >> on the forum because it could have a impact on power constraint device >> and because it was limited to discovery in rare occasion, now that we >> herd of the problem related to the event I think we should reconsider >> the issue > > Or maintaining a second version of the driver? Cause on apache felix > download page you also find 2 versions :) > Well...but 17 devices arent really that much if you ask me! Hmmz > > > Well - kind regards, > Daniel > > > -----Ursprüngliche Nachricht----- > Von: Stefano Lenzi [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 25. Juli 2008 17:41 > An: [email protected] > Betreff: Re: AW: AW: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver > 0.8 ........m-search the problem? AH ... one more note... > > Daniel Felsing wrote: >> I know that you're the same stefano lenzi :) >> The message was just copied from a mail directed to you and francesco. >> >> >> And what would fix my problem u think?... >> Cause you've now heard a lot by my posts..i'm curious what u think could >> solve the issue.. >> Cause IF it is really caused by UDP messages this issue will always occur > if >> someone will release a lot of devices (well 17 aren't really a lot but ok) >> using the upnp base driver. And a smart home can have a LOT of devices in > it >> :) > > UPnP event are meant to be best-effort because they are meant to be > non-critical information which if lost will be received in the next > changing of the value or anytime the device decide to send the event. > We probably should try to updated the CyberDomo and the CyberLink stack > in way to make it more Thread, but we also keep in consideration power > constraint device, because our goal is to make the UPnP Base Driver run > either on JDK1.3 and embedded system. > Up to now we have neglected to fix the CyberDomo with the patch propose > on the forum because it could have a impact on power constraint device > and because it was limited to discovery in rare occasion, now that we > herd of the problem related to the event I think we should reconsider > the issue > >> >> Btw.: i did a workaround in my code.. > > That's good :) > >> I'm internalising the upnp eventing in my layered architecture to a "event >> admin" bus sending unified messages. >> The initial message i send now when the object (which is refining >> upnpdevice) is created by getting the values by the offered >> upnpaction.invoke. >> >> --------> Is invoke done by TCP? Cause then my initial eventing is safe > from >> now on :) <----------- > > Yes it is :) > >> >> Status updates i get by upnpsubscriber which does a upnpnotify on my >> refining objects...and they are only internalised to my bus if variables >> really change >> >> And logoff messages on my event admin bus are sent when the refining > driver >> removes the object and calls destroy on it... >> >> >> :) >> >> Kind regards, >> Daniel >> >> -----Ursprüngliche Nachricht----- >> Von: Stefano Lenzi [mailto:[EMAIL PROTECTED] >> Gesendet: Freitag, 25. Juli 2008 16:39 >> An: [email protected] >> Betreff: Re: AW: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8 >> ........m-search the problem? AH ... one more note... >> >> Daniel Felsing wrote: >>> Please Mr Lenzi...take a look at that... >>> >>> >>> Is it possible that my issue is connected to this one mentioned in the >>> cyberlink forum? >> Yes it is possible but only because we are speaking about the UDP >> communication >> >>> Stefano answered to it in the cyberlink forum!! >>> http://sourceforge.net/forum/forum.php?thread_id=1952657&forum_id=258158 >>> >> I'm the same Stafano Lenzi whom is cited in the thread >> >>> take a look at it...is this issue already fixed in the current base > driver >>> of felix? >> No it has not yet integrated and it won't fix your problem anyway >> >>> >>> 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] >> >> >> > > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- 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]
