Author Topic: TCP socket issues  (Read 5508 times)

Offline neil

  • Sr. Member
  • ****
  • Posts: 438
    • View Profile
TCP socket issues
« on: January 19, 2011, 10:42:52 AM »
Hi Mark,
  I have a couple of issues with the TCP socket (which I am sure its something I am missing ). I have created a socket as follows and put into listening mode:

USOCKET socket
socket=fnGetTCP_Socket(TOS_MINIMISE_DELAY, (unsigned short)20, fnTCPListener);
fnTCP_Listen(socket, TCP_INPORT, 0);

int fnTCPListener(USOCKET Socket, unsigned char ucEvent, unsigned char *ucIp_Data, unsigned short usPortLen)
{
   TCP_MESSAGE test_message;

    switch (ucEvent) {
    case TCP_EVENT_CONNECTED:
                      ....
                     break;
    case TCP_EVENT_CLOSE:
                       fnDebugMsg("Port 1919: TCP_EVENT_CLOSE\r\n");
      
    case TCP_EVENT_CONREQ:                                              
    case TCP_EVENT_ARP_RESOLUTION_FAILED:
        break;
        
   case TCP_EVENT_PARTIAL_ACK: fnSendBufTCP(Socket, 0, usPortLen, TCP_BUF_NEXT);break;
   case TCP_EVENT_ACK: fnSendBufTCP(Socket, 0, 0, TCP_BUF_NEXT);break;  
         
    case TCP_EVENT_REGENERATE:
       break;
    case TCP_EVENT_DATA:
             ...
        break;
    case TCP_EVENT_ABORT:
    case TCP_EVENT_CLOSED:
           fnTCP_Listen(Socket, TCP_INPORT, 0);                    // go back to listening state
              fnDebugMsg("Port 1919: Closed\r\n");
        break;
        }

    return APP_ACCEPT;
}

After my windows application connects, and data is sent.

1. If the application doesnt receive info within 5 seconds from the windows application, it is assumed that the connection is lost for some reason, and by doing a fnTCP_close(socket)  command the TCP_EVENT_CLOSED command wont be called (as the windows app wont ack the closure). As within the TCP_EVENT_CLOSED command I place it back into fnTCP_Listen() for a normal closure, would I simply put it back into fnTCP_Listen() after I do the fnTCP_close() command ,w ithout worrying that it would cause an issue?

2.  I though the command: fnGetTCP_Socket(TOS_MINIMISE_DELAY, (unsigned short)20, fnTCPListener);  will have a 20 second timeout if connection has been idle for 20 seconds. The socket times out in 60 seconds instead of 20.

Regards
Neil
« Last Edit: January 19, 2011, 10:54:07 AM by neil »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: TCP socket issues
« Reply #1 on: January 22, 2011, 03:46:36 PM »
Hi Neil

1) It is normal to set the socket back to the listener state on either TCP_EVENT_ABORT or TCP_EVENT_CLOSED. The TCP_EVENT_CLOSED is called once the connection has successfully been terminate (after the FIN has been acked so that both sides have closed). The TCP_EVENT_ABORT is the error case in which situation the connection has already broken down (for some reason).

2) When testing the idle timer make sure that you account for any closing delay (eg. due to repetitions in the code if the peer is not connected).
Also check the TCP.c in the latest Beta version : http://www.uTasker.com/software/V1.4/uTaskerV1.4_M52259TWR_Beta.zip [30.11.2010]
I didn't see any changes that corrected too long delays though.

I just tested a connection with 20 and it timed out after 20. In case you don't find a reason for it taking longer, monitor the link timer in fnPollTCP() in TCP.c which should count down once a second

                    if (ptr_TCP->usLinkTimer != INFINITE_TIMEOUT) {      // if idle timer not disabled
                        ptr_TCP->usLinkTimer--;                          // count down idle period
                    }



Regards

Mark