LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Client - Server slow tcp/ip...

Hi,

I have come across something that I believe does not necessarily depend
upon LabView but on the standard itself. I'm talking about a client-
server application using TCP/IP. I would like to have a server that
reads 4 consecutive packets decide upon the data received and
transmits 4 packet back to the client. There is no problem doing so
disregarding the fact that the connection becomes unbearably slow. If
I, instead of reading 4 consecutive packet on the server reads 1, sends
1 and then reads the rest, I speed up the link by a factor of 40! Both
the methods works without corrupting any data (I have double checked
that the variable sizes received and transmitted are correct).

Is there anyone that has come across the same?
Is this caused by the
TCP/IP standard or is it results of my bad programming?

Sincerely


/Nimrod


Sent via Deja.com http://www.deja.com/
Before you buy.
0 Kudos
Message 1 of 2
(3,222 Views)
I'd be interested to hear a more detailed description of the problem:

>I have come across something that I believe does not necessarily depend

>upon LabView but on the standard itself. I'm talking about a client-
>server application using TCP/IP. I would like to have a server that
>reads 4 consecutive packets decide upon the data received and
>transmits 4 packet back to the client. There is no problem doing so
>disregarding the fact that the connection becomes unbearably slow. If
>I, instead of reading 4 consecutive packet on the server reads 1, sends

>1 and then reads the rest, I speed up the link by a factor of 40! Both
>the methods works without corrupting any data (I have double checked
>that the variable sizes received and transmitted are correct).

I'm a little confused by talk about IP packets when programming at a
high level like LabVIEW, because you rarely have to consider individual
packets and packet content when approaching TCP/IP communications
problems. (in my experience, at least)

The usual problems with client/server apps are latencies brought about
by incorrect network configurations and timing issues--the logic of
ensuring that the client reads what the server sends at the appropriate
times.

A good point of comparison for timing issues is the Date Client/Server
example that ships with LabVIEW. That example demonstrates a similar
technique to what you describe: the first 4 bytes of a new transmission
always represent an I32 value that tells the client how many bytes of
data are to follow. The larger the follow-up chunks, the better the
data throughput, but this technique should never result in "unbearably
slow" communications.

If things really are that slow, you may well have a DNS problem. You
could try using the actual IP addresses of the two machines and seeing
if that speeds things up. If so, your two machines probably aren't
resolving one another's hostnames properly. If not, and you're pretty
sure that there's no network problems, then you should troubleshoot by
examining your client and server dataflow and making sure that the two
sides are working together as you intended.

Best Regards,
John Lum
National Instruments
0 Kudos
Message 2 of 2
(3,221 Views)