09-16-2013 08:32 AM
I am facing one problem with the tcp.
my device is now able to setup connection and transfer data. once I give a command from pc the tcp connection is closed using "TCP Close Connection". even after this, the device will again try to establish a connection by trying to send an arp request. if I run the VI again, it shows "port number reused" in wireshark.
eventhough,I have disconnected properly why is it telling so?
if send a syn pack to PC, it is replying with ack instead of syn ack?? is it because I am not closing the port? doesn't "TCP Close" do it??
09-16-2013 11:07 AM
I don't have enough information to understand exactly what is happening; a WireShark capture would help.
TCP requires that both ends close the connection. It's not sufficient for you to use TCP close; your device must also close the connection. Also, you cannot reuse the same combination of server/client ports for several minutes, in order to guarantee that a new connection doesn't receive delayed data from an old connection. If your device always tries to establish a connection from the same source port, you'll need to wait before establishing a new connection. It would be better to pick a new source port at random each time you connect from the client to the server.
09-17-2013 03:50 AM
I have attached the wireshark capture.
I will list important places in the wireshark to make it comfortable for you.
start - connection established
till 106 - full of retransmission.
then window size of tcp if full. so data starts sending again..
after this, there is no problem.(no retransmissions)
at 1032 - exit is sent from PC. It closes connection in labview and device also responds for it.(this stops the labview as well)
the device is programmed to always look for connection. so it send arp request even after that.
at 1050 - labview started. but still connection is not establishing.. PC is sending 'ack" instead of "syn ack" as a reply to "syn" from device..
this continues..
at 1103 - a "rst" is given from PC.. after this connection establishes..
then retransmission for some time..
then proper communication...
my questions are "what decides when rst signal sent by PC?", "why connection establishes after 'rst' ?" , "during retransmission there was seperate "ack" from PC. when not after that?" ," why transmits well after window gets full ? "
09-17-2013 12:41 PM
I'm sorry I can't be too helpful, but I do not know enough about the low-level details of TCP nor how your operating system (Windows, probably?) implements it to be able to help here.
I can tell you that even if you properly close the TCP connection, you still MUST wait a certain amount of time before you reuse the same pair of source and destination ports. This prevents confusion in case packets arrive out of order and a packet is received for a connection that's already closed. If the connection was reopened immediately on the same port pair, the receiver wouldn't know if the packet was stale data from the old connection or valid new data. The correct design is to choose a new source port at random each time you open a new connection, instead of reusing the same port for every connection.
It looks to me like you still have a lot of possible TCP errors. You might want to set up a test where you use two known good endpoints (for example, simple LabVIEW programs running on two different computers) and capture a TCP exchange between them to see a correct TCP data transfer.