TCP read

[080 5120 8600]

Hi,

I have problem with TCP read. I created client  using LABVIEW on PC .

Server is FPGA board.

I could send the data from FPGA to PC. And I could read the data using this client.

I am sending data continuously from FPGA to PC. 

But LABVIEW client is receiving only the first send data. I Am using the TCP Read VI in a while loop.

Should I handle Acks after every read? What might be the problem?

[paulmw]

You should post this message in the LabVIEW message board.

Do you know how many bytes to expect?  Are you reading all of them?  A simple implementation is to have the first byte be the lenght of the packet.  So you would read the first byte first and then read the rest based on the first byte's value.  You may want to post your VI (or equivalent example) so we can see what you are attempting.  An explanation of the data being sent wouldn't hurt either.

Message Edited by paulmw on 10-25-2006 07:34 AM

[080 5120 8600]

I am sending the 200 packets each of 100 bytes. I could receive only 5 packets of 100 bytes through the TCP read VI.

If the sending speed is greater than receiving speed, Will TCP read VI  receive what ever data comes to it when it is getting executed OR Will it have buffers to handle all the data?

[paulmw]

You may want to try an Ethernet network protocol analyzer program.  Ethereal, which looks like it is now called Wireshark, is a good tool to capture all the trafic comming to your network device.   It is free to download.  With this tool you should be able to comfirm that your device is infact sending all 200 packets.

I would assume that it would be buffered fine (500 bytes is not a lot)  but I am not an expert by any means.  Are you doing a read of 100 bytes for each read?  Does the read timeout?

I suppect that your device stops sending data since you do get 5 of those packets (use Wireshark to see if there is any other data).  If you are worried about the buffering, can you implement a protocol where your device only sends one packet at a time and waits to send the next packet until your host acknowledges that it receive the packet?

[080 5120 8600]

Hi,

Does TCPread VI send Ack after receiving the  data? And does TCP send VI wait for the Ack for sending the next packet?

Or those Acks should be handled outside the VIs?

[080 5120 8600]

HI,

How TCPread and TCPWrite VIs work? Do they handle Ack number and seq numbers?

While sending, what Ack and Seq Numbers TCPWrite use? Is it from recently received packet?

Waiting for the reply..

[RobertoBozzolo]

You should really post this question in the LabVIEW forum as Paul already suggested: only a few users of this board use LV as well as CVI and it may be that they have never used these vis, as it is my case.

Since you are now digging into the specific of some VI, it's better that you address the right community of users.

[Justin D]

All of the ack's are handled by the low-level TCP protocol, not LabVIEW.  You don't have to send or wait for any ack's.  The TCP functions in LabVIEW operate like the TCP functions in any other language.  All the user has to deal with is sending data to a specified ip address and port and waiting for connections.

-Justin D

[080 5120 8600]

Thanks for the information.

Should I handle any timing issues here?

[NIJanell]

Hello 080,

I'm not quite sure what you mean by "Should I handle any timing issues here?"  Do you mean timing issues in general or specifically associated with TCP?  Either way, as many other members have suggested and especially if this thread is going to veer from the topic of acks, I highly suggest that you create a new thread under the LabVIEW discussion forums instead of the LabWindows/CVI forums.  When you create the new thread, include a link to this one.  You will get a much faster and more thorough response as there are many more LabVIEW users compared to CVI users who know LabVIEW.

Have you implemented Paul's suggestion of monitoring how much data is actually being sent?  Isolating whether the issue is on the sending or receiving side will be critical to move forward in our troubleshooting.

Happy Halloween!

Janell R | Applications Engineer