Help with Technique Please

[zener]

I am programming a LV application that looks for a tcp host at a certain IP address and port number to recieve a data stream every second. As well, it will look for a Fieldpoint module at another address. After it does this, it begins a while loop to parse out and display the data aquired. I need to have the VI check for these connections periodically, and use them if available, however, I don't want it to error out or quit if it does not find one or the other. In short, I need it to be somewhat "self healing" if the host computer or fieldpoint module should be disconnected. Perhaps an example. I can e-mail my current VI upon request. Thanks

[altenbach]

Could you give a little more information.

Does you application open a connection to that IP/port and request data every second with a brand new TCP connection or does it open a connection once and keep it open for the duration of the experiment.

Is that server actively streaming the data and you are just listening? Does it matter if data is missed? If not, it might be much easier to use UDP.

How does the data look like? (short strings of equal length, variable lenght but terminated, random)

You definitely need the two communications to the two nodes in two seperate loops so they can run asynchronously without blocking each other.

If all participants are LabVIEW programs, have you considered using Datasocket instead?

[zener]

Opens once and keeps open. Server is a labwindows based program that will send upon tcp connect. Server sends data once a second. Data consists of 100 data points ascii, 2 decimal places. Preceeded by a time/date stamp.
I can use Datasocket. What would be the advantage? I am somewhat new to Labview so excuse the vi here. I have programmed in Labwindows since it originally came out.

[DougD]

altenbach:

TCP is very easy to implement in LabVIEW and UDP is not a recommended
protocol to use for network communications when data acquisition
and/or hardware control is involved. UDP datagrams unlike TCP packets
are NOT guaranteed to be delivered across a network. The UDP sender
sends the message out into the network cloud and if it gets lost on
its way to the receiver, too bad...

I have personally seen the consequences (on a Unix C application) of a
UDP "datastorm" when datagrams aren't delivered but a client waiting
on them is expecting them and when it doesn't get them it fails and
reports the failure to the server which then gets tied up restarting
the failed client and the result is a cascade of client failures
resulting in a "datastorm"
which brings down the whole network. It
wasn't fun, it required shutting down the server application and all
the remote clients and then restarting the whole network. (P.S.:
WASN'T MY CODE, I was just the unlucky user...)

Douglas De Clue
ddeclue@bellsouth.net

altenbach wrote in message news:<506500000005000000368B0000-1023576873000@exchange.ni.com>...
> Could you give a little more information.
>
> Does you application open a connection to that IP/port and request
> data every second with a brand new TCP connection or does it open a
> connection once and keep it open for the duration of the experiment.
>
> Is that server actively streaming the data and you are just listening?
> Does it matter if data is missed? If not, it might be much easier to
> use UDP.
>
> How does the data look like? (short strings of equal length, variable
> lenght but terminated, random)
>
> You definitely need the two communications to the two nodes in two
> seperate loops so they can run a
synchronously without blocking each
> other.
>
> If all participants are LabVIEW programs, have you considered using
> Datasocket instead?

[altenbach]

> UDP datagrams unlike TCP packets are NOT
> guaranteed to be delivered across a network.

Douglas,

Well, even TCP packets are not guranteed, e.g. if I cut your cable 😉
My suggestion for UDP was tied to the sentence "Does it matter if data is missed?". If this is the case, UDP is much more fault tolerant, because it is stateless. For example given a simple weather station sending a packet with time and temperature every second. Missed packets can easily be interpolated or treated as missing (put a sequence number in the packet and you'll know how much you're missing). UDP is better in this case!
If you would implement this in TCP, you need to establish a connection, lost packets will be retransmitted, and if the connection breaks down o
r is really flakey all these retransmissions compound the problem. If one side reboots, a new connection must be established from scratch.
Using UDP, each side can restart and simply join the party again. You can add some statefulness using a second UDP channel to communicate current operation status. UDP data can even be sent to the subnet broadcast address with the following two advantages:
(1) Any node can listen in, e.g. several monitoring nodes can display the same ongoing data.
(2) Nodes that are not listening, will not return ICMP(3,3)packets, but simply ingore broadcasts.

In any case, if it brings down the entire network, it is probably due to a coding error and not due to choice of IP protocol. I could easily write you a SYN-flooder that brings down the entire network (DoS attack) using only TCP.

[Jeremy Braden]

I have not tried this myself specifically for TCP commands, but I have a suggestion. Unbundle the error cluster to determine the error state after a TCP command. If an error occurs, you have a case structure fire a wait or set a flag that controls future TCP operations. You can use the error code (numeric) to have the case responds to specific errors. Also, the case structure can be used to trap out errors by outputing non error cluster constants to the error in of the next VI.

Jeremy

[DougD]

zener:

It is a tricky business just killing off errors.

You can use the general error handler VI to kill off errors that
result from failed attempts to open connections to i/o etc. In
TCP/IP, the most typical errors that occur of this type are errors 56
and 63. You basically want to give the general error handler VI these
error numbers and tell it to cancel on match for these codes.

You could tell it to cancel any errors that it encounters by taking
the error number out of the error cluster, feeding it into the general
error handler and telling it to cancel on match, but I wouldn't
recommend this because it could be an important error and you would
never know.

Even if you cancel the error because of a failure to connect, you will
still need to set up a case box or something similar so that you can
make sure that you don't then attempt to read data from a connection
that failed to open etc.

Alternatively, you may want to put the attempt to open in some sort of
while loop that keeps trying until it is successful.

If you are communicating with PLC's for data acquisition purposes only
then it is less critical if you fail to make a connection but even
then you need to let the operator know the status of the connection on
the user interface, etc. so he knows whether he has live data or not.

If you are communicating PLC's for hardware control purposes, then it
is much more critical that you think through the consequences of a
failure to connect, a PC crash, or a bad block of data sent, from a
safety and property point of view. Plan how you intend to handle
these failures so that your code will be as bullet proof as you can
possibly make it.

Douglas De Clue
LabVIEW developer
ddeclue@bellsouth.net





zener wrote in message news:<50650000000800000003520000-1023576873000@exchange.ni.com>...
> I am programming a LV application that looks for a tcp host at a
> certain IP address and port number to recieve a data stream every
> second. As well, it will look for a Fieldpoint module at another
> address. After it does this, it begins a while loop to parse out and
> display the data aquired. I need to have the VI check for these
> connections periodically, and use them if available, however, I don't
> want it to error out or quit if it does not find one or the other. In
> short, I need it to be somewhat "self healing" if the host computer or
> fieldpoint module should be disconnected. Perhaps an example. I can
> e-mail my current VI upon request. Thanks

[DougD]

altenbach:

Agreed if it doesn't matter if you miss, then UDP is better and faster
than TCP. In my case, it definitely "mattered" that data was missed.
I would assume that it would "matter" in most LabVIEW applications in
that we are usually in the business of acquiring data from some other
device or controlling some other device and bad things tend to happend
when we "miss" a frame of data.

Douglas De Clue

altenbach wrote in message news:<506500000005000000528C0000-1023576873000@exchange.ni.com>...
> > UDP datagrams unlike TCP packets are NOT
> > guaranteed to be delivered across a network.
>
> Douglas,
>
> Well, even TCP packets are not guranteed, e.g. if I cut your cable 😉
> My suggestion for UDP was tied to the sentence "Does it matter if data
> is missed?". If this is the case, UDP is much more fault tolerant,
> because it is stateless. For example given a simple weather station
> sending a packet with time and temperature every second. Missed
> packets can easily be interpolated or treated as missing (put a
> sequence number in the packet and you'll know how much you're
> missing). UDP is better in this case!
> If you would implement this in TCP, you need to establish a
> connection, lost packets will be retransmitted, and if the connection
> breaks down or is really flakey all these retransmissions compound the
> problem. If one side reboots, a new connection must be established
> from scratch.
> Using UDP, each side can restart and simply join the party again. You
> can add some statefulness using a second UDP channel to communicate
> current operation status. UDP data can even be sent to the subnet
> broadcast address with the following two advantages:
> (1) Any node can listen in, e.g. several monitoring nodes can display
> the same ongoing data.
> (2) Nodes that are not listening, will not return ICMP(3,3)packets,
> but simply ingore broadcasts.
>
> In any case, if it brings down the entire network, it is probably due
> to a coding error and not due to choice of IP protocol. I could easily
> write you a SYN-flooder that brings down the entire network (DoS
> attack) using only TCP.

[Ben]

Hi Zener,

Use UDP for the host conection. It by default is "self healing".

Ben

[mikeporter]

There are several issues that need to be thought-out here. First, TCP as implemented in LV has one very big problem, if a connection drops betweent he time you open it and the time you try and use it LV hangs and never times out. The only way to recover is to abort and then restart the application that is attempting the TCP transfer.

Second, TCP is slow. All its handshaking can take a long time.

Third, there is nothing wrong with using UDP. You just have to be prepared to provide the error checking and fault recovery yourself--which is not really a very big problem.

I have uder development a set of VIs for transfering datafiles using UDP as the transport layer and a protocol something like the old YModem protocol sitting on top of it. The result is a rob
ust transfer capability that is significantly faster than TCP.

Mike...