tonymy01 wrote:I should read PeterU's message again, but didn't he then suggest that access to the device should always be via the IP address and not the arbitrary name, in which case you can deal with two devices just fine, and it is simply the nice presentation of the information/device name listing showing the name rather than IP address that will cause end user ambiguity?
Regards
On re-reading peteru's suggestion, there's a bit that I'm not sure I understand, and it's
peteru wrote:At the end of the day, the device name is only a user visible label that should play no role in the network traffic portion of the application. The key used for all the lookups should be ip_addr:port, not the device name.
It's always been possible to tell getWizPnP to connect to a device at a specific IP,port address. In fact, that used to be the only way that getWizPnP worked under Windows.
The way that it currently works is like this:
- getWizPnP (or any other WizPnP client) asks: Are there any WizPnP servers out there?
- All the WizPnP servers respond with a packet that contains (among other stuff): My name is X and my presentationUrl is http://my.bw.ip.ad:port/index.txt.
- getWizPnP waits until it has received maxdevs responses, or if maxdevs is 0, it waits until it's timed out (currently the default --wizpnpTimeout=0.3 sec).
- The above is repeated up to --wizpnpPoll=3 times, or until maxdevs devices have responded.
- Each response is stored in an associative array indexed by the device's name in the response packet (which is taken from SETUP>Network>WizPnP>Name, and which defaults to 'beyonwiz') if there isn't already an entry in the array under that name.
If there is more than one entry in the array, the user must specify which device they want to use using the --device option. When getWizPnP connects to the device it uses the scheme and login parts of the presentationUrl to establish the connection, so no further ambiguity is introduced here.
This gives peteru's initial suggested behaviour:
peteru wrote:Your application should perform a single discovery at the start of a run and remember the name to address mapping for the remainder of that execution. If one name resolves to multiple addresses, you should use the first response and ignore the others
The problem with this (and recognised later in peteru's post), is that the first response for a particular name doesn't necessarily come from the same device on each run of getWizPnP, so if you do a --list operation, and select a recording, and then do a --delete operation on the same device name, the second operation might be attempted on a different device from the first, because different devices with the same name may have responded first.
So, peter suggested:
Your application should perform a single discovery at the start of a run and remember the name to address mapping for the remainder of that execution. If one name resolves to multiple addresses, you should use the first response and ignore the others
If I use peter's suggestion (his first part is what getWizPnP already does), then I will implement this, too.
I will also implement this part of peter's suggestion:
If you feel that it is important to deal with misconfigured networks (multiple devices with same name), then I would suggest that you print a warning for any duplicates
If I implement it this way, the result of doing a --discover on a network with devices "DP-S1" (10.1.1.2:49152), "DP-S1" (10.1.1.3:49152) and "DP-H1" (10.1.1.4:12345) will be something like:
Code: Select all
DP-S1 10.1.1.2:49152
DP-S1 10.1.1.3:49152 Duplicate device name: not accessible
DP-H1 10.1.1.4:12345
The list will be ordered by name, than IP address, then port number. This gives the WizZilla authors the option of only using the first (or any entry) for each name, or using all discovered devices.
getWizPnP is a command-line tool, not GUI-based, so that some things that are simple and natural to do in a GUI can be ugly and inconvenient to do from the command line.