TCP Write loosing packages

[Kunze]

Dear,

When I use TCP Write in fast succession (immediate one after the other) TCP packages are lost.

When I program 3 time TCP Write just one after the other the 3rd packages is lost.

Doing it in the same way with a timed loop of 1ms it works propperly.

So what is going on in LabVIEW?

Any Ideas?

Kind regards

Martin

[Mark_Yedinak]

It would help to actually see the code that does not work. I have never encountered any timing related issues with writing data quickly (as fast as possible) using the TCP primatives. I suspect you have some other code issue but it is impossible to see that without seeing the actual code.

[altenbach]

Your question is way too open ended. Most likely, the packet is sent out but the receving end is not ready, for example. How do you detect that a packet is missing? At what point after the timed loop is the connection closed? Do you get any error messages?

Who is receiving the transmission? Who wrote the receiving code? How big are the strings you are sending?

Do you see the transmission if you e.g. run wireshark on each end?

(I am not sure what a "package" is. did you mean "packets"? LabVIEW does not care about packets, in fact a long message could be fragmented into many packets, but you don't need to worry about any of that lowlevel stuff).

[Kunze]

The original code ist just the same without the loop.

Simply three times a TCP write in a row.

When wire shark or etherreal tells you that there is no package than ther is no package.

The receiver is allwas ready since it is a peer to peer with 100Mbit/s

The question is:

Has anyone else had this failure in LabVIEW 2011 too or not.

[altenbach]

Are you running wireshark on the sender or in the receiver end?

TCP is designed to run un unreliable networks, and packet loss always occurs at some level, at which case the missing packet is retransmitted.

A TCP connection is initiated with a threeway handshake and both sides keep track of every single packet. Packets can arrive out of order, some missing, even some in duplicate, and the receiver will make sense of it, reassemble, and request retransmissions.

Your third message is part of the same TCP connection so it is difficult to image it go missing unless one of the sides resets the connection prematurely.

---

Kunze wrote:

The receiver is allwas ready since it is a peer to peer with 100Mbit/s

---

What does network speed have to do with readiness? What program is receiving the packets and who wrote it?

Did you update the network drivers?

Can you attach filtered wireshark traces, one recorded on each side, showing all communication between these two nodes?

[Kunze]

This is a LabVIEW problem!

No doubt about it!

When I do the last message in a none timed loop 10 or hundret times all messages are lost too.

[Kunze]

I have also thought about the receivers disablility to receive data but wire shark is running on the sender system an so it seams like LabVIEW doesn't send the message anyway.

[altenbach]

Can you attach some simple code that demonstrates the problem?

[Mark_Yedinak]

Post your actual code, not pictures. Post a copy of your Wireshark trace. Simply stating that it is a LabVIEW problem (which I have my doubts about given the amont of TCP I have used) without giving us anything else to look at won't help you resolve your issue.