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: users@felix.apache.org
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: users@felix.apache.org
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]
