IP client question

tracktoys

I am fairly new to IP communications for devices. That being said, I have a question about the client/server relationship and how it pertains to my situation. Here is a rundown of what I am trying to do:

I have an NI-3000 master on a network with an Aurora Multimedi WACI Jr. that I am using as a web server for touch panel pages. I have a client setup in the master for receiving the command strings (telnet port 23) from the WACI, which get parsed out in my master to make thing happen with my devices. The client goes dormant in the master after 3 minutes of inactivity, at which point it will ignore any further strings from the WACI. To get it back in line I had a temporary function that issues IP_CLIENT_CLOSE(), a short wait, then IP_CLIENT_OPEN(). My solution was to basically force the client open with a timeline (90 seceond heartbeat) that sends a 'ping' to the WACI, which will then send a 'PONG' to the master. This along with some other code allows me to verify connectivity and keeps the port open.

My question is this, is it OK to leave that particular client open constantly listening for strings from the WACI? Is there a better way for the master to listen to the telnet port and open the client only when it sees something coming in?

Chip Moody

If you're using a client to connect, then sit and wait for data to come in from the device acting as a "server", then no - you'll want that connection open at all times. I would look into some kind of "heartbeat" message you can either enable on the WACI - something meaningless it can sent every minute to keep the connection alive - or a message you can send >to< it from the NetLinx for the same result. In this case, it would be something sent to the WACI that doesn't cause any change in the WACI, and generates a response you don't really care about or need...

- Chip

tracktoys

I have a 'ping' ~ 'pong' setup going back and forth between the 2 now to keep the client connected. I tried to force the issue with this arrangement to try and teach myself how to communicate via IP. I am thinking about reconnecting the serial ports to avoid the hassle of possible network failure. Thanks for responding to this issue, Chip.

a_riot42

tracktoys wrote: »

My question is this, is it OK to leave that particular client open constantly listening for strings from the WACI? Is there a better way for the master to listen to the telnet port and open the client only when it sees something coming in?

Perhaps I don't exactly understand what you are trying to do, but the string event will get run if you have a data_event for a telnet port. IP isn't a session based protocol, so there is no point in keeping a socket open. You open it, send your data, close it, open it, send your data, close it etc.

data_event[dvTelnetPort]
{
  string:
  {
    print(data.text)
  }
}

Paul

jweather

a_riot42 wrote: »

IP isn't a session based protocol, so there is no point in keeping a socket open.

IP is not session-based, but TCP is, and that's what you're using here. There is an overhead involved with setting up and tearing down each connection, both in network traffic and in latency. You also have to send traffic to keep a connection alive, though, so there's a tradeoff. For most applications, it doesn't matter which way you do it. Many A/V devices such as projectors seem to have issues with keeping connections open for very long, so they may behave better if you open a connection, send a command, then close the connection.

Jeremy

Thorleifur

Don?t know if this is relevant but...

My latest project has 24 Hitachi projectors, of various models, all connected to one master via IP. I opt to have the connection open all the time to all projectors. I may be an overkill to do so, but it works for this project. If my customer wants to change the input of the projector it will be instant.
I keep the connection live with some types of KeepAlive commands or just ask the projector if they are turned on and what input they are on.

I just use the code from TechNote 621 about Netlinx Client IP Connection. In the beginning of my IP programming I made some minor adds to the code like a counter to know how long the connection has been open and how often it has been opened for my benefit. The connection has been solid in my old projects and re connections few also.
I have been having some problems with the FIRST_LOCAL_PORT command sometimes. Not serius ones but ones that can cost an hour or so to resolve. If you misspell anything in 0:dvDEVICE.port:0 ( like 0:dvEVICE.port:0) you will get a Major System Error and no line to check. So have fun going through all you code. But I still use it. I live on the edge

I have a little experience with network administration so I have demands for the network part of my projects.
1. My network has to have a good backbone. ( let?s face it, good Ethernet switches are just expensive "power"strips, but there are good ones and bad ones out there. When using just 3 LAN devices the switch really doesn?t matter, but when you have 32 devices scattered around it can matter.)
2. I have a closed LAN for my equipment! If not- see below.
3. My own IP scope! If they can.
4. When using configurable switches, my port shall be closed to all other traffic other than my own.
5. NO OCD Network Administrators.
IF (OCDNA)
{
ON[dvbBUGGING,OCDNA]'
IF (nUGETWHATUWANT = 1)
{
OFF[dvbBUGGING,OCDNA]
}
}
6. Port security shall be off

Fortunately the sales team at my company respect my wishes and they try to accommodate.

Hedberg

Thorleifur wrote: »

My latest project has 24 Hitachi projectors, of various models, all connected to one master via IP. I opt to have the connection open all the time to all projectors. I may be an overkill to do so, but it works for this project. [...]

I don't think there is anything wrong with keeping IP clients open and sometimes it's necessary. For example, there are a bunch of RS232 over ethernet server devices out there and if the client is closed after information is sent to the device then responses and other information from the remote device will not make it through. Depending on the device, some sort of traffic may be necessary every once in a while to keep the connection open. The little Extron RS232 over ethernet devices are like that. Of course, you probably already know all this, so my apologies for being redundant.

VLCNCRZR

Server or Client

tracktoys wrote: »

I have an NI-3000 master on a network with an Aurora Multimedi WACI Jr. that I am using as a web server for touch panel pages. I have a client setup in the master for receiving the command strings (telnet port 23) from the WACI, which get parsed out in my master to make thing happen with my devices.

I have not done a whole lot with IP control, but I was under the impression that this type of
communication (AMX listening for commands from a TCP/IP device) would require a
IP_SERVER_OPEN, not an IP_CLIENT_OPEN.

It has been a long week, and maybe I am not thinking straight.

Hedberg

VLCNCRZR wrote: »

I have not done a whole lot with IP control, but I was under the impression that this type of
communication (AMX listening for commands from a TCP/IP device) would require a
IP_SERVER_OPEN, not an IP_CLIENT_OPEN.

It has been a long week, and maybe I am not thinking straight.

It makes more sense that if you were listening for something that you would want a server rather than a client, but it depends on what you are connected to. It depends on whether the non-Netlix device will function as a client or not. If it will only function as a server, then I think you have no choice but to use a client on your master and keep it open. If the "remote" device will function as a client, then you could do a server on your master and just have it respond to client connections and requests, as necessary.