This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Closing TCP Connection

Hi everyone,

I'm trying to send data using the booster pack cc3000 by Texas Instruments. Therefore I implemented a TCP server socket on my board. I can accept a pending connection and send and receive data on the given socket successfully. In my protocol the client is responsible for closing the connection after reading the response. But after some transmissions the transmissions becomes slow. If I inspect the WLAN traffic using Wireshark I see there is a problem with the socket close procedure. My client is a java based program. The board uses address 100 and the computer runs under 102.

  The TCP stream looks the following:

31 4.696711000    192.168.2.102         192.168.2.100         TCP      66     50721 > http-alt [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
 32 4.700359000    192.168.2.100         192.168.2.102         TCP      58     http-alt > 50721 [SYN, ACK] Seq=0 Ack=1 Win=1460 Len=0 MSS=1460
 33 4.700394000    192.168.2.102         192.168.2.100         TCP      54     50721 > http-alt [ACK] Seq=1 Ack=1 Win=17520 Len=0
 34 4.700461000    192.168.2.102         192.168.2.100         HTTP     55     Continuation or non-HTTP traffic
 35 4.705454000    192.168.2.100         192.168.2.102         TCP      54     http-alt > 50721 [ACK] Seq=1 Ack=2 Win=1460 Len=0
 36 4.705476000    192.168.2.102         192.168.2.100         TCP      57     [TCP segment of a reassembled PDU]
 37 4.709035000    192.168.2.100         192.168.2.102         TCP      54     http-alt > 50721 [ACK] Seq=1 Ack=5 Win=1460 Len=0
 38 5.194961000    192.168.2.100         192.168.2.102         TCP      58     [TCP segment of a reassembled PDU]
 39 5.196220000    192.168.2.100         192.168.2.102         HTTP     154    Continuation or non-HTTP traffic
 40 5.196244000    192.168.2.102         192.168.2.100         TCP      54     50721 > http-alt [ACK] Seq=5 Ack=105 Win=17416 Len=0
 41 5.196286000    192.168.2.102         192.168.2.100         TCP      54     50721 > http-alt [FIN, ACK] Seq=5 Ack=105 Win=17416 Len=0
 42 5.202194000    192.168.2.100         192.168.2.102         TCP      54     http-alt > 50721 [ACK] Seq=105 Ack=6 Win=1460 Len=0
138 24.245036000   192.168.2.100         192.168.2.102         TCP      54     http-alt > 50721 [FIN, ACK] Seq=105 Ack=6 Win=1460 Len=0
139 24.245060000   192.168.2.102         192.168.2.100         TCP      54     50721 > http-alt [ACK] Seq=6 Ack=106 Win=17416 Len=0

After about 10 transmissions I get a FIN/ACK cascade. The last FIN/ACK above is part of this cascade. It looks like if the sockets are not completely closed and the HW module starts now closing all sockets in a row.

My Java - Client does the following:

    Socket b = new Socket("192.168.2.100",8080);
    OutputStream o = b.getOutputStream();
    o.write(10);
    o.write(0);
    o.write(0);
    o.write(0);
    o.flush();

    InputStream i = b.getInputStream();

    int id = i.read();
    int gId = i.read();

    int lengthA = i.read();
    int lengthB = i.read();
    int length = (lengthB<<8)|lengthA;
    if(length < 0|| length > 1000)
    {
        b.close();
        return;
    }

    System.out.println(new Date()+" GantryID: "+gId+" Package with id: "+id+" has length: "+length+" payload: ");

    DataInputStream ds = new DataInputStream(i);
    byte[] buffer = new byte[length];
    ds.readFully(buffer);       
    b.close();
    System.out.println(new String(buffer));

The server opens a server port and start non blocking accept to serve pending requests. When a new request is due the communication runs the following:

     return recv(handle, data, size, 0); //Read request header
     return recv(handle, data, size, 0); //Read request payload
     send(handle, data, size, 0); //Write response header
     send(handle, data, size, 0); //Write response payload
     //No Close only set socket handle to -1

Does anyone have a idea what is going on?

Many thanks,

Jonny

  • Hi Jonathan,

    The TCP connection termination procedure looks alright. In this case, it looks like the CC3000 has entered a CLOSE_WAIT state, where a close socket command from the remote side was received when the CC3000 was receiving the data.

    As you are not calling a closesocket at CC3000 side, the CC3000 will wait for the time-out to occur before sending its FIN,ACK packet to the client. Until the time-out occurs, the CC3000 will be in CLOSE_WAIT state.

    Thanks & Regards,
    Raghavendra

  • Hi Raghavendra,

    thank you for your response. As far as I know only one side of the connection has to close the socket. Otherwise two FIN/ACKs are send which are resulting a TCP reset package. Or am I wrong with this? All the data is received and send successfully by the cc3000 board. So I can hardly imagine the remote system closes the socket to early.

    Many Thanks,
    Jonathan

  • Hi Jonathan,

    If a device in a TCP connection has initiated a close sequence by sending a FIN,ACK, then a TCP connection would be considered as completely closed only after the 4 way termination sequence has been completely executed.

    Apart from this, another way to close a TCP connection is by using the RST flag, which will bring down the connection when something unusual happens.

    Thanks & Regards,
    Raghavendra

  • Jonathan,


    Wikipedia has a good overview on how establishing and closing a connection works.

    http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_termination

    /Pontus