Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Control point with multiple adapters
12-11-2012, 12:12 PM
Post: #1
Control point with multiple adapters
If a control point application wants to search for and use devices on multiple adapters, is it possible to do this with a single instance of the ohNet library?

From reading the code, I have the impression that the control point stack is limited to a single adapter, and the library is limited to a single control point stack. If this understanding is correct, the control point application would need to create two separate instances of the ohNet library. Are there any issues with creating multiple instances of the ohNet library within a single process?
Find all posts by this user
12-11-2012, 01:39 PM (This post was last modified: 12-11-2012 01:43 PM by simonc.)
Post: #2
RE: Control point with multiple adapters
Its correct that the control point stack can only operate on a single subnet at a time. There is no easy way to get around this.

Creating two ohNet instances within a single process won't work without (unplanned) changes. ohNet uses a small amount of global data (mainly the Stack class and platform-specific Os.c files); this would need to be removed before we could have two instances in the same address space. This refactoring would be possible but would take a moderate effort and be source incompatible (requiring Cp or Dv stack instances to be passed into most contructors). There are currently no plans to make these changes.

Sorry, not a terribly positive answer. If you can say more about what you're trying to do, I'll see if there are any easier ways of making the current code cooperate.
Find all posts by this user
12-11-2012, 02:07 PM
Post: #3
RE: Control point with multiple adapters
(12-11-2012 01:39 PM)simonc Wrote:  Its correct that the control point stack can only operate on a single subnet at a time. There is no easy way to get around this.

Creating two ohNet instances within a single process won't work without (unplanned) changes. ohNet uses a small amount of global data (mainly the Stack class and platform-specific Os.c files); this would need to be removed before we could have two instances in the same address space. This refactoring would be possible but would take a moderate effort and be source incompatible (requiring Cp or Dv stack instances to be passed into most contructors). There are currently no plans to make these changes.

Sorry, not a terribly positive answer. If you can say more about what you're trying to do, I'll see if there are any easier ways of making the current code cooperate.

Based on this information, having two ohNet instances doesn't seem like the right way to go. If it were possible to extend the control point stack to handle multiple adapters, that seems like a much cleaner solution. Another option would be to allow multiple control point stacks to be started within the same UPnP library.

The issue is that people are running MinimWatch (a UPnP control point that monitors and controls MinimServer devices) on machines wth two network adapters. At present, MinimWatch chooses the first adapter in the subnet list and uses this to create the control point stack. This usually selects the right adapter, but sometimes it doesn't. The design of MinimWatch means it's not easy for me to add a configuration setting for the user to choose an adapter, and this also wouldn't work if people have MinimServer devices reachable via both of the adapters.
Find all posts by this user
12-11-2012, 04:37 PM
Post: #4
RE: Control point with multiple adapters
(12-11-2012 02:07 PM)simoncn Wrote:  Based on this information, having two ohNet instances doesn't seem like the right way to go. If it were possible to extend the control point stack to handle multiple adapters, that seems like a much cleaner solution. Another option would be to allow multiple control point stacks to be started within the same UPnP library.

I'm afraid this wouldn't be easy either. Device lists would become much more complicated to maintain (which isn't desirable as they're one of our main sources of bugs already). Subscription management would become a little trickier too.

Not all control point applications would want such behaviour either. A single subnet limit is better for controlling a media renderer for example as it avoids the risk of detecting a renderer and server on different networks which have no direct route to each other.

If we were to make any change towards support for additional subnets, it'd likely be via your earlier suggestion of allowing multiple ohNet instances per subnet. And even this would be more work than I could commit to I'm afraid.

(12-11-2012 02:07 PM)simoncn Wrote:  The issue is that people are running MinimWatch (a UPnP control point that monitors and controls MinimServer devices) on machines wth two network adapters. At present, MinimWatch chooses the first adapter in the subnet list and uses this to create the control point stack. This usually selects the right adapter, but sometimes it doesn't. The design of MinimWatch means it's not easy for me to add a configuration setting for the user to choose an adapter, and this also wouldn't work if people have MinimServer devices reachable via both of the adapters.

I think your best option might be to run multiple MinimWatch instances, one per subnet. Or, if this isn't palatable, to reconsider adding user selection of subnet to MinimWatch.
Find all posts by this user
12-11-2012, 05:06 PM
Post: #5
RE: Control point with multiple adapters
(12-11-2012 04:37 PM)simonc Wrote:  Not all control point applications would want such behaviour either. A single subnet limit is better for controlling a media renderer for example as it avoids the risk of detecting a renderer and server on different networks which have no direct route to each other.

I had assumed that the single vs. multiple adapter selection would be made by the control point application, just as it is currently for devices.

Quote:I think your best option might be to run multiple MinimWatch instances, one per subnet.

I'll think about this. It might not be too difficult to implement, as I should be able to use the Java Runtime.exec() API to fork a new process under the covers from within MinimWatch without the user being aware that this is happening.
Find all posts by this user


Forum Jump: