TCP connection in labview and C program

[chris]

Hi there,
I have a server program written in C and running under linux, it
accept connection from client and send series of data to client
through TCP socket. I was using the "simple data client.vi" as the
client.
I tried to send integer number 1, 2,3.. , but the client failed to
correctly decode the data since it read everything as string. I was
wondering if there is a solution to read binary data in labview TCP
connection? I really don't want to encode the double into string and
send it to client through TCP socket in my server program, since it's
not efficient.
thanks !

[Greg_McKaskle2]

> I have a server program written in C and running under linux, it
> accept connection from client and send series of data to client
> through TCP socket. I was using the "simple data client.vi" as the
> client.
> I tried to send integer number 1, 2,3.. , but the client failed to
> correctly decode the data since it read everything as string. I was
> wondering if there is a solution to read binary data in labview TCP
> connection? I really don't want to encode the double into string and
> send it to client through TCP socket in my server program, since it's
> not efficient.
> thanks !
>

The string is often used in LV as a general buffer. Type Cast the
string as the appropriate integer and it should be fine. If the integer
has been transmitted in litt
le endian byte order, you will need to use
the Advanced byte and word swapping functions in LV in order to reorder
the integer contents -- LV always assumes big-endian binary format.

Greg McKaskle

[Rolf]

No problem with sending and receiving binary data over the TCP/IP VIs. Just
Flatten them before sending and unflatten them after receiving. Beware of
the
byte order, however. LabVIEW always assumes BigEndian or Network byte
order (MSB) for flattened data.
Since you say that you have a Linux app chances are that you run on ix86
architecture and if you don't take any provisions on your server side you
are
ending and expecting LittleEndian (LSB) data on the server side.

This can be fixed by wiring the Swap Words and Swap Bytes on the LabVIEW
side before the Flatten function or after the Unflatten function, but this
is only a
quick fix.

A more portable approach would be to always use Network byte order on your
server side. With correct conditional macros you can even reco
mpile the
server
on non ix86 architectures and still get the exact same byte stream protocol.

Rolf