TCP comm with multiple instruments

[CoastalMaineBird]

It's not right to assume that, just because a message was sent with one TCP WRITE operation, it will be received in one TCP READ operation, is it?

I just did a test, where I ask the instrument for a response and then enter a loop:

For i := 0 to 9999

   N = StrLength(TCP_READ(Immediate, Timeout=0))

and graphed all the N's I get back.

All the values are 0 except one, around loop 200-210, which is 56 bytes - that's my message.

I tested it 10 times or so, but I can't depend on that behavior, can I?

[dan_u]

---

@CoastalMaineBird wrote:

probably even simpler, ask all handlers for their current data.

I don't think I can do that.  I'm sampling at 10 Hz.  At SAMPLE time, I need the data and I need it NOW (in addition to these 5-50 instruments, I have 250+ channels of other stuff [SCXI, CAN, MIO, DIO, other TCP instruments] which I need to sample NOW).

I don't want to be asking 50 questions to 50 different instances to get it.

If one of the handlers is in the WAIT state, waiting for data, then it's not able to respond to a request from the host.

---

Then you could turn it around: instead of asking the handlers for the current data you can keep the current data of all instruments in the master, and the handlers will push a new value to the master whenever it is available (using a queue, notifier, AE or some other method). Will be kind of asynchronous, but I think this is unavoidable in this setup.

[CoastalMaineBird]

Thanks, Ben

Are you suggesting that the multi-instance "spawned" handlers is actually LESS burdensome than the buffer-it-myself approach?

[dan_u]

---

@CoastalMaineBird wrote:

If one of the handlers is in the WAIT state, waiting for data, then it's not able to respond to a request from the host.

---

(Sorry for double post)

This would, in my opinion, be a design flaw. The communication from the handlers to the master should always be responsive even if communication from a handler to the instrument is interrupted or in a WAIT state.

[Ben]

TCP guarentees the packets are delivered in the order they were recieved sent and intact. So provided your widget is not sending disjointed pcakets, I think you can expect what you observed.

Quoting from the wiki

---

 TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer.

---

Ben

[dan_u]

---

@CoastalMaineBird wrote:

It's not right to assume that, just because a message was sent with one TCP WRITE operation, it will be received in one TCP READ operation, is it?

---

No, you can't rely on that afaik. The order remains correct, but you might need several read operations depending on your read method.

[Mark_Yedinak]

No, that is not a safe assumption. You may get away with it for small messages but if you have larger data sets it is quite likely it will be seen in multiple messages. Most intelligent TCP stacks will try to send the data in the largest sized packets as possible. Generally this is roughly 1400 to 1460 bytes of data. It depends on if any TCP options are included in the TCP header. Stacks will generally buffer data before putting in one the network and wait for a brief delay before sending small packets. This is the Nagle algorithm. However the stack could send a single byte at a time. This would be very inefficient it can happen. Given network delays this could mean your message arrives in multiple packets separated by some length of time. The more complex the network between the two ends of the conversation the greater the delays will be.

[CoastalMaineBird]

This would, in my opinion, be a design flaw.

Agreed, but this is where we came in, trying to avoid that very scene.

If I just spawn the separate handlers, and let them run independently, with their ask-wait-receive sequences, then nothing has really changed.

They could be in the WAIT state when I want data, and unable to respond to me (the master).

[Ben]

doing the broken record thing...

TCP implements a packet seq number to ensre that nothing is dropped and everything is in order. If a packet is dropped or delayed no data will bubble up through the TCP stack until the missing packet is recovered (via retries) or a time out occurs.

IP handles the details of breaking up the packets to fit on the network and ensure no correption by an inserted CRC for each packet.

Ben

[CoastalMaineBird]

OK, Mark, thanks.  I believe you're right, judging from (fuzzy) memory of reading the nuts and bolts of it some years ago.

I am in a complex network, with a Host and PXI and maybe 8 other TCP instruments, and some ENET chassis, so I know some collisions will occur and some bits will die by the side of the road.

So, if I do the buffering myself, I have to allow for the possibility that my 56-byte message would arrive in 60 separate TCP READ operations.

There is some overhead to all the shuffling around if I do the buffering.

If only the dang instrument would send a CRLF (which it will do if you choose RS232), or if I could change the TCP_READ to have a LF mode...