You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Daniel Felsing <da...@maven.at> on 2008/07/25 13:06:16 UTC
AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8 ........m-search the problem? AH ... one more note...
Just forgot...
AND why do the "lost" event updates do not get propagated in future???...
I can start the m-search..manually...and if there would be any states
missing they should be delivered ANYTIME in the future...but they simply
dont...the upnp tester does not get notified for hours...
Kind regards,
Daniel
-----Ursprüngliche Nachricht-----
Von: Stefano Lenzi [mailto:kismet@interfree.it]
Gesendet: Freitag, 25. Juli 2008 12:48
An: users@felix.apache.org
Betreff: Re: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8
........m-search the problem?
Daniel Felsing wrote:
> Nah...
> The more i look into the problem the more patterns appear in my head. ;-)
>
> In fact there is no difference...i ran tests with m-search and
without...the
> behavior can be considered the same.
> Server randomly receives no notification...
>
>
> Ok - i have tried the following now:
>
> Running the "upnp test event listener which subscribes to every upnp
event"
> in two different ways on the host which exports the upnp devices.
>
> - starting the event tester in the SAME osgi framework runs fine...
This seems to proof my theory, to be a UDP best-effort communication issue
.
> - starting the event tester in a second osgi framework on the same host
(no
> network connection in between) gives me the same behavior as on running
over
> a network cable. So some events still missing then.
Because the two OSGi Environment communicate by means of the Network so
it's the same as testing on the remote computer
>
>
> Btw: i NEVER experience a problem with devices...every device is always
> found in every single test.
>
That's good :) I assure you that you may not discover some device in
certain situation...
>
>
> So i have two different things which i'm note sure:
>
> - Either the flooding is causing the problems...so maybe upnpbasedriver
> should be adapted to be not that fast in sending out events?
It may be the UPnP Stack, namely the patched CyberLink driver aka
CyberDomo, to be modified to fix the problem in general
> - or there is something wrong with (initial) "event" delivery....
I'll bet for the best-effort communication, because the test that you
performed on a single OSGi environment proved that the event are sent by
the UPnP Device, so the problem seems to be the receiver over the network.
If you want to perform more test you should sniffer the packet sent on
the network by means of Wireshark and check that the importing host
receive all the UDP with all the event of all the device exported by the
remote host. (The test may be performed also on a single computer with
two OSGi platform running)
>
> Kind regards,
> Daniel
>
Ciao,
Stefano "Kismet" Lenzi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8 ........ISSUE from cyberlink forum....
Posted by Daniel Felsing <da...@maven.at>.
Hi Stefano and Francesco,
Is it possible that my issue is connected to this one mentioned in the
cyberlink forum?
Stefano answered to it in the cyberlink forum!!
http://sourceforge.net/forum/forum.php?thread_id=1952657&forum_id=258158
take a look at it...is this issue already fixed in the current base driver
of felix?
Kind regards,
Daniel
-----Ursprüngliche Nachricht-----
Von: Daniel Felsing [mailto:daniel.felsing@maven.at]
Gesendet: Freitag, 25. Juli 2008 13:06
An: users@felix.apache.org
Betreff: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8
........m-search the problem? AH ... one more note...
Just forgot...
AND why do the "lost" event updates do not get propagated in future???...
I can start the m-search..manually...and if there would be any states
missing they should be delivered ANYTIME in the future...but they simply
dont...the upnp tester does not get notified for hours...
Kind regards,
Daniel
-----Ursprüngliche Nachricht-----
Von: Stefano Lenzi [mailto:kismet@interfree.it]
Gesendet: Freitag, 25. Juli 2008 12:48
An: users@felix.apache.org
Betreff: Re: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8
........m-search the problem?
Daniel Felsing wrote:
> Nah...
> The more i look into the problem the more patterns appear in my head. ;-)
>
> In fact there is no difference...i ran tests with m-search and
without...the
> behavior can be considered the same.
> Server randomly receives no notification...
>
>
> Ok - i have tried the following now:
>
> Running the "upnp test event listener which subscribes to every upnp
event"
> in two different ways on the host which exports the upnp devices.
>
> - starting the event tester in the SAME osgi framework runs fine...
This seems to proof my theory, to be a UDP best-effort communication issue
.
> - starting the event tester in a second osgi framework on the same host
(no
> network connection in between) gives me the same behavior as on running
over
> a network cable. So some events still missing then.
Because the two OSGi Environment communicate by means of the Network so
it's the same as testing on the remote computer
>
>
> Btw: i NEVER experience a problem with devices...every device is always
> found in every single test.
>
That's good :) I assure you that you may not discover some device in
certain situation...
>
>
> So i have two different things which i'm note sure:
>
> - Either the flooding is causing the problems...so maybe upnpbasedriver
> should be adapted to be not that fast in sending out events?
It may be the UPnP Stack, namely the patched CyberLink driver aka
CyberDomo, to be modified to fix the problem in general
> - or there is something wrong with (initial) "event" delivery....
I'll bet for the best-effort communication, because the test that you
performed on a single OSGi environment proved that the event are sent by
the UPnP Device, so the problem seems to be the receiver over the network.
If you want to perform more test you should sniffer the packet sent on
the network by means of Wireshark and check that the importing host
receive all the UDP with all the event of all the device exported by the
remote host. (The test may be performed also on a single computer with
two OSGi platform running)
>
> Kind regards,
> Daniel
>
Ciao,
Stefano "Kismet" Lenzi
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
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...
Posted by Robert Koberg <ro...@koberg.com>.
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:kismet@interfree.it]
> > 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:kismet@interfree.it]
> >> 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: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: AW: AW: AW: AW: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8 ........m-search the problem? AH ... one more note...
Posted by Daniel Felsing <da...@maven.at>.
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/users@felix.apache.org/msg01781.html
please take a look at it :)
Kind regards,
Daniel
-----Ursprüngliche Nachricht-----
Von: Francesco Furfari [mailto:francesco.furfari@isti.cnr.it]
Gesendet: Freitag, 25. Juli 2008 20:28
An: users@felix.apache.org
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:kismet@interfree.it]
> 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:kismet@interfree.it]
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
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...
Posted by Francesco Furfari <fr...@isti.cnr.it>.
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:kismet@interfree.it]
> 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:kismet@interfree.it]
>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
AW: AW: AW: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8 ........m-search the problem? AH ... one more note...
Posted by Daniel Felsing <da...@maven.at>.
>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:kismet@interfree.it]
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:kismet@interfree.it]
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: AW: AW: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8
........m-search the problem? AH ... one more note...
Posted by Stefano Lenzi <ki...@interfree.it>.
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:kismet@interfree.it]
> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
AW: AW: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8 ........m-search the problem? AH ... one more note...
Posted by Daniel Felsing <da...@maven.at>.
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
:)
Btw.: i did a workaround in my code..
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 :) <-----------
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:kismet@interfree.it]
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: AW: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8
........m-search the problem? AH ... one more note...
Posted by Stefano Lenzi <ki...@interfree.it>.
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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
AW: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8 ........m-search the problem? AH ... one more note...
Posted by Daniel Felsing <da...@maven.at>.
Please Mr Lenzi...take a look at that...
Is it possible that my issue is connected to this one mentioned in the
cyberlink forum?
Stefano answered to it in the cyberlink forum!!
http://sourceforge.net/forum/forum.php?thread_id=1952657&forum_id=258158
take a look at it...is this issue already fixed in the current base driver
of felix?
Kind regards,
Daniel
-----Ursprüngliche Nachricht-----
Von: Stefano Lenzi [mailto:kismet@interfree.it]
Gesendet: Freitag, 25. Juli 2008 16:02
An: users@felix.apache.org
Betreff: Re: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8
........m-search the problem? AH ... one more note...
Daniel Felsing wrote:
> Just forgot...
>
> AND why do the "lost" event updates do not get propagated in future???...
>
> I can start the m-search..manually...and if there would be any states
> missing they should be delivered ANYTIME in the future...but they simply
> dont...
Because the packet containing the information is sent by means of UDP
packet which if lost the sender doesn't get aware of it.
> the upnp tester does not get notified for hours...
Because it receive only the next event which arrives only when the
"evented variables" change its value
>
>
> Kind regards,
> Daniel
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: AW: AW: AW: AW: AW: AW: bug in felix upnp basedriver 0.8
........m-search the problem? AH ... one more note...
Posted by Stefano Lenzi <ki...@interfree.it>.
Daniel Felsing wrote:
> Just forgot...
>
> AND why do the "lost" event updates do not get propagated in future???...
>
> I can start the m-search..manually...and if there would be any states
> missing they should be delivered ANYTIME in the future...but they simply
> dont...
Because the packet containing the information is sent by means of UDP
packet which if lost the sender doesn't get aware of it.
> the upnp tester does not get notified for hours...
Because it receive only the next event which arrives only when the
"evented variables" change its value
>
>
> Kind regards,
> Daniel
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org