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.... - 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. Btw: i NEVER experience a problem with devices...every device is always found in every single test. 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? - or there is something wrong with (initial) "event" delivery.... Kind regards, Daniel -----Ursprüngliche Nachricht----- Von: Stefano Lenzi [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 25. Juli 2008 11:54 An: [email protected] Betreff: Re: AW: AW: AW: AW: bug in felix upnp basedriver 0.8 ........m-search the problem? Hi Daniel, Please look at my comments below. Daniel Felsing wrote: > Can it be that the "ongoing" m-search is influencing the status notification > behavior? Yes > > I started a manual m-search while starting my upnp event tester on the > server side, cause i thought maybe there was a problem with some leases or > something. > But the situation got even worse. Missing devices propagated their status > when status change occurs (e.g. by pressing a switch). > > Now while m-search was going on in background the device didnt respond for a > certain time.. i kept pressing the switches and after some while it started > to respond. > I guess this was the case when m-search was completed... > > So what if the initial m-search is the problem? > If you start the osgi framework the m-search is done initially by the driver > i guess... Yes you are right, you can request more M-SEARCH from the UPnP Tester developed by us while this process is going on my upnp event listener is > registering and wants to know the status. > And maybe thats the cause for the "lost" stati? In fact, I asked you in my previous e-mail if you can receive the notification on the "exporting" computer and if you have a network connecting only the two computers. In general the problem is that the event notification is transported by means of UDP packet, hence the OS may discard it if it receives too many packet at the same time. The "Too many packets" event be caused by the following reason: anytime the UPnP Driver receive a packet it have to process it in the same thread before reading the next packet, hence the OS buffer the other request, but the buffer may not be enough if the number of packet is big. At the end, my opinion the way to check where is the problem is: 1 - Check if you can receive event on the exporting computer 2 - If you receive packet try to test the overall architecture with less sensor Ciao, Stefano "Kismet" Lenzi --------------------------------------------------------------------- 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]
