Can we get someone to respond from a country whose subject line response indicator is 'MV:' for a little balance.
On Fri, 2008-07-25 at 20:28 +0200, Francesco Furfari wrote: > 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]
