Home AMX User Forum NetLinx Studio

Controlling many IP devices - best approach?

I've programmed (non AMX) projects where I've had to control and monitor over 300 IP devices and I'm just wondering what's the best approach for doing this in NetLinx.

Do you guys normally define an IP client device (i.e. LocalPort) for each device to control or just use one LocalPort and handle its use within your queuing mechanisms?

Ok that was clear as mud so here's an example:

Say we have 10 projectors. Do you define your IP LocalPorts like this:
DEFINE_DEVICE
dvProjectorIPClient1	= 00:03:00
dvProjectorIPClient2	= 00:04:00
dvProjectorIPClient3	= 00:05:00
dvProjectorIPClient4	= 00:06:00
dvProjectorIPClient5	= 00:07:00
dvProjectorIPClient6	= 00:08:00
dvProjectorIPClient7	= 00:09:00
dvProjectorIPClient8	= 00:10:00
dvProjectorIPClient9	= 00:11:00
dvProjectorIPClient10	= 00:12:00

and use those 10 different IP Client connectors individually for each projector. Advantages are you can keep the connections open and receive DATA_EVENTS without worry. This wouldn't scale to over 255 devices would it?

Or just define a single IP connector that you re-use (IP_CLIENT_OPEN / do stuff / IP_CLIENT_CLOSE) for each projector operation:
DEFINE_DEVICE
dvProjectorIPClient	= 00:03:00

and use your queuing code to communicate with each projector one at a time and re-using the single IP Client connector?

The second method allows you to control a practically unlimited amount of devices but at the expense of DATA_EVENTs triggering; the code has to sit around and wait for responses from the device before you can move onto the next one. Very linear and potentially quite slow.

Obviously you could create multiple IP connectors for each class of device so you're not totally bottlenecked.

Or have I missed something totally fundamental?!

Many thanks in advance.

Comments

  • viningvining Posts: 4,368
    The masters can only have 200 ip connection at a time but realistically a lot less than that. There was good post on this but I couldn't find it. To do that many ip devices you'll need several master, probably just use ni-700 or 900's and divide them up. I would define them all as in you 1st example and maintain the connection if it makes sense to do so.
  • Ah I wondered what the hard connection limit was - thanks for that.

    Yeah I thought about the multi-master approach which I guess is the best way if you need to maintain connections with the devices.
  • viningvining Posts: 4,368
    regallion wrote: »
    Ah I wondered what the hard connection limit was - thanks for that.

    Yeah I thought about the multi-master approach which I guess is the best way if you need to maintain connections with the devices.
    Here's the link I was looking for. Post 5

    http://www.amxforums.com/showthread.php?7268-Maximum-number-of-NI-XXXX&highlight=Max+ip+connections
  • Cheers for that.

    I just had another thought - I could create an array of LocalPort devices with "in use" flags assigned to each one.

    Then when my device queues need to do some comms they can pick up an unused LocalPort from the pool - do their stuff then release it again. This will still allow me to have "unlimited" devices (obviously within reason) but not slow stuff down too much as each device will be able to grab any free LocalPort.

    Hmmmm......
  • viningvining Posts: 4,368
    Yeah if they don't need to be controlled or monitored at the same time then just create an array like you suggested. Just dertimine the max possible connections you could possibly ever need and reserve those port for use by the array.
  • Most of the projects I've been involved in the past are basically performing a systems management role; so start of day will wake up a crap load of projectors, PCs, media players etc. Then systematically poll each device throughout the day doing health checks and alerting on any problems.

    So yes I think this is the approach I'll take for now.

    Thanks for your input!
  • a_riot42a_riot42 Posts: 1,624
    regallion wrote: »

    and use your queuing code to communicate with each projector one at a time and re-using the single IP Client connector?

    The second method allows you to control a practically unlimited amount of devices but at the expense of DATA_EVENTs triggering; the code has to sit around and wait for responses from the device before you can move onto the next one. Very linear and potentially quite slow.

    Obviously you could create multiple IP connectors for each class of device so you're not totally bottlenecked.

    Or have I missed something totally fundamental?!

    Many thanks in advance.

    I would use only one port and communicate with any similar devices over that port. Having multiple ports doesn't get you much since the CU is single threaded. The Kaleidescape module is a good example where they use one IP port for up to 32 players and touch panels.
    Paul
  • I think that's a good point, I'm used to programming mutli-threading control devices.

    I actually knocked up some test code to grab a free LocalPort from a pool and it worked fine but I don't think it's gaining me much! Think I'll go back to the single LocalPort for each device type as you say!

    Thanks guys.
  • viningvining Posts: 4,368
    a_riot42 wrote: »
    I would use only one port and communicate with any similar devices over that port. Having multiple ports doesn't get you much since the CU is single threaded. The Kaleidescape module is a good example where they use one IP port for up to 32 players and touch panels.
    Paul
    How exactly is that working? I see this in the code:
    /*
     * Kaleidescape recommends using the server as the single
     * point of connection.  That way if any player is turned off,
     * the rest of the system will still function.
     */
    
        //send_command KPLAYER1, 'IP 10.100.12.112'    
        send_command KPLAYER1, 'IP 10.100.12.143'
    
    but that makes me think the module only talks to the server and the server in turn is talking to the players. If the module talked to the player there should also be a section where they define the IPs of all the players.

    I never used K-Scape but I was curious to see what interesting connection scheme the module was doing but I don't see it. Of course according to my wife I am 1/2 blind and 3/4 stupid so am I missing it.
  • a_riot42a_riot42 Posts: 1,624
    vining wrote: »
    but that makes me think the module only talks to the server and the server in turn is talking to the players. If the module talked to the player there should also be a section where they define the IPs of all the players.

    I never used K-Scape but I was curious to see what interesting connection scheme the module was doing but I don't see it. Of course according to my wife I am 1/2 blind and 3/4 stupid so am I missing it.

    Yes the module talks to the server and the server relays commands to the players although you can have multiple servers too. Perhaps that wasn't a good example, my point is that when you open a socket you pass the IP address to the function, send the data, and then typically the socket is closed. When you have to send the next command even if its to a different IP address, you might as well use the same port rather than a different one.

    One thing I haven't tried is sending to a string to an array of ports like this:

    send_string dvArrayOfPorts, "'PWR'"

    I don't see why it wouldn't work but I haven't tried it before. If you have 10 sockets in an array, you could potentially send a string to each with one send_string.
    Paul
Sign In or Register to comment.