Multiple Browse actions do not work reliably

Multiple Browse actions do not work reliably

Hi,

I'm developing a control point for a Home Automation package using the .NET SDK. I have been able to successfully detect and partially browse MediaServers on my network. I'm using the InvokeSync method from the UPnPService class to execute a "Browse" action on a MediaServer. When I do successive "Browse" actions I don't reliably get responses. The first "Browse" gets a response, but subsequent "Browse" actions respond intermittently. The InvokeSync method just hangs when there is no response.

The interesting thing is that if I insert a 15 second delay between "Browse" actions, it works perfectly. Clearly, this is a workaround, but it takes a very long time to fully browse the MediaServer on my network. Is this behavior by design, or is it a symptom of something I'm doing wrong.

A few notes on my configuration:

  • My media server is Twonkyvisions' V3.1
  • VB.NET is the development language in Visual Studio 2005

I would appreciate any help.

Thanks,

-John

3 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Hi,

My first suggestion is to actually use the Asynchronous APIs. I have never encountered any such issues using those APIs. I have found scenarios where Windows tries to be "intelligent" about it's threads and actually attempt to keep threads waiting in the hopes that another thread will free up. For example, if you use the System Thread Pool, and block one of the threads, sometimes future calls to dispatch work to the thread pool will block until one of the threads has freed, even if there are free threads in the pool.

If you are unfamiliar or uncomfortable with using Asyncronous programming designs, I would look through your code to make sure that you aren't holding any locks on any of the system threads. In this case, the system thread would be any thread on which one of the upnp callbacks is dispatched on. If those threads are blocked, it may prevent future callbacks from occuring, because of said optimizatons.

I'm also not sure which version of the intel UPnP C# stack you are using, but I found that if you are using .NET/2.0, Microsoft changed the default threading behavior in the system. If you use the v2718 of the tools, you won't need to worry about the problem I'm about to describe:

There is a new flag in the socket object that MS defined,called "UseOnlyOverlappedIO". This value must be set to true. If it is set to false, I found that .net will use the System ThreadPool to dispatch callbacks, which causes many problems, and may be the source of your problems.

Thanks for the reply. There was a newer version of the SDK posted earlier this year that cleared up the problem.

Thanks,

-John

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui