TCP read/write at different rates

[FLng]

Objectives:

1) TCP write at 1 kHz

2) TCP read at 100 Hz

Not sure why, but the loop collecting the data and performing the TCP write will stop around 20 iterations.

I'm guessing that there is a better way to accomplish the 2 objectives than the way I tried.

[Andrey_Dmitriev]

I haven't DAQ right now, so can't test it, but if you want to write data to TCP (N bytes per iteration) with 1kHz, then you must read N*10 bytes on the reader side with each iteration - then you will get 100 Hz, isn't?

See "Quick and dirty" example in attachment (based on your SubVIs)

Andrey.

[FLng]

Sorry for the confusion, but I want the client to open 2 TCP/IP connections:

1) One that writes a 32 byte TCP data packet (the minimum TCP data packet size) to the server at 1 kHz.

2) Another that reads a 32 byte TCP data packet from the server at 100 Hz.

[Chris_G.]

Hello Fred,

It is true that if you read slower than you are writing the data, you will eventually end up with a timeout error on the side of the writer.  Perhaps an example of what you mentioned in your last post (two connections being opened) would give us a better idea of what you are attempting to do.

[CoastalMaineBird]

I don't understand your situation.

You "want the client to open 2 TCP/IP connections", but your "client on Target" VI opens only one. 

It's perfectly legal and possible to have two connections at two different rates (or 20 at 20 different rates).

But you have to open them both on the client, and listen for them both on the server. 

You'll have to use 2 different ports. 

I have a blog entry that might help you: Beginner's guide to TCP/IP

Also, I don't know where you get the idea that a packet must be 32 bytes.

I routinely send 3-byte packets without problems.

[CoastalMaineBird]

In hopes of clarifying things a bit for you, I have added a blog entry that offers an example of four TCP connections, running at four different rates, each transmitting an 8-byte message.

The Next Step In TCP/IP 

Hope that helps. 

[FLng]

CoastalMaineBird,

Please excuse me as I'm new to TCP/IP.  Unfortunately a coworker told me that the minimum TCP data packet size was 32-bytes, and I accepted this w/o checking.  As I searched around, I couldn't find anything supporting this, so I've asked for an explanation.

Also, you were right about the vi's I posted; there needed to be 2 connections opened.  I accidentally attached an older version.  Since then I've figured out how to accomplish the original goals.

I just looked at the link you posted, and recommend other users reading this thread to check it out.

Thanks to those who responded to this thread.

[Mark_Yedinak]

Actually the minimum data length for a TCP packet will be bytes. The minimum size packet on an Ethernet link is 64 bytes. The Ethernet header is 14 bytes long, the IP header is 20 bytes and the TCP header is 24 bytes. This means the a minimum size packet on an Ethernet link will have six bytes of TCP data. You can technically send data single byte of data but the packet itself will be padded to include 6 bytes of data. Some lower stacks will also delay sending packets for a very short time in hopes of filling the packet. So, if you write a single byte packet the packet may not hit the wire immediately. The stack may hold it briefly in case additional data was going to be written. Either way, you can have a TCP packet with a single byte of data.

[CoastalMaineBird]

You can technically send data single byte of data but the packet itself will be padded to include 6 bytes of data. 

That's as may be, but if I send a 1-byte message, then the other end gets a 1-byte message, and the pad bytes are invisible, immaterial, and irrelevant.

At the higher layers we are operating at, there's nothing to be done about them. So I say ignore them.  

Especially for beginner's level TCP.

[Mark_Yedinak]

What you say is essentially true. However, it is possible for more data to be available then expected at the receiver's port. The stack will try its best to send as few packets as possible across the network to optimize throughput. If the sender sends 6 single byte messages more likely than not they will all be sent in a single data packet. Is is the receivers responsibility to read and interpret the data correctly. If the receiver simply reads one byte at a time all is well. If it were to read more than a single byte (assuming we are using single byte messages) it could consume more than one byte of data.

As long as the sender and receiver know what the data looks like it is fairly straightforward to keep them in sync with each other without using any type of addiitonal protocol. If on the other hand your data will be variable length data then you will need to have some mechanism for deliniating the data.