user socket

[neil]

Hi Mark,
 I want to use TCP sockets for incoming and outgoing connections. The incoming connection will not be HTTP port 80, I wish to use another port. Do I still #define USE_HTTP within config.sys? And I assume that I set USER_TCP_SOCKETS to the number of sockets I wish to use (does this include incoming connections too) ?

Regards
Neil

[mark]

Hi Neil

If you don't define USE_HTTP it will remove the HTTP server. If you don't need the HTTP server but only other TCP connections you don't need USE_HTTP.

Every socket (a socket can be listener or client, or both) needs to be taken from the socket pool so the pool must be declared to have enough sockets available. When using non-standard sockets (HTTP, FTP etc. are standard and define the socket count needed automatically) simply increment USER_TCP_SOCKETS for each socket that you will need to use.

Regards

Mark

[neil]

Hi Mark,

  As I am planning to use 1 incoming connection (TCP), and 6 outgoing connections, is there any reason why I cant use 1 callback function for outgoing and incoming communications?

Regards
Neil

[mark]

Hi Neil

This should be OK. You must certainly start the socket listening so that it can accept incoming connections but you can still use it as a client (assuming not yet connected) by starting a connection.

Regards

Mark

[neil]

Hi Mark,
  After a socket is allocated with command fnGetTCP_Socket(..) , will there never be any need to call this function again?

I set the timeout of the socket to 10 seconds (as below), and made sure there was no activity . The connection timed out in 70 seconds, why is this (my windows application made the connection, and made sure there was no traffic)? Perhaps there is a minimum value?

fnGetTCP_Socket(TOS_MINIMISE_DELAY, (unsigned short)10, fnTCPListener);

Regards
Neil

[mark]

Hi Neil

You only need to call the fnGetTCP_Socket() once if you never use fnReleaseTCP_Socket().

I just tested FTP with a 10s timeout

FTP_TCP_socket = fnGetTCP_Socket(TOS_MINIMISE_DELAY, 10 /*usFTPTimeout*/, fnFTPListener);

This timed out out correctly after 10s.

Try the following:

1. In tcp.c put a break point in the timeout code
                else if (!(ptr_TCP->usLinkTimer)) {                      // idle time out                   
                    ptr_TCP->ulNextTransmissionNumber++;
                    ptr_TCP->ucSendFlags = (TCP_FLAG_ACK | TCP_FLAG_FIN);
                    fnSendTCPControl(ptr_TCP);
                    fnNewTCPState(ptr_TCP, TCP_STATE_FIN_WAIT_1);                       
                    ptr_TCP->event_listener(Socket, TCP_EVENT_CLOSE, ptr_TCP->ucRemoteIP, ptr_TCP->usRemport); // inform application of timeout and link closing
                }

2. Put a break point in the re-trigger code (also in tcp.c)

        case TCP_STATE_ESTABLISHED:
            ptr_TCP->usLinkTimer = ptr_TCP->usIdleTimeout;               // retrigger the keep alive timer since there is activity
            break;

Start the project and establish a connection. It will trigger at 2 two times quickly after another. Then it should timeout without any activity after the defined number of seconds.

If it triggers at 2 in the meantime it will restart the timer.

The basic timing is performed by the tcp task (it is called once a second to count down the timers).

I couldn't find a problem with my tests - can you identify something at your end?

Regards

Mark

[neil]

Hi mark,
  Intead of placing breakpoints, I simply sent a string through the serial port and watched on hyperterminal.  Here is steps the application done:

1.. processor made connection..  -->send a message when connected in TCP_EVENT_CONNECTED

2. on windows application I set breakpoint on my c++ code, so I know there is no communication after a connection is made...

3. a message displayed twice at 'case TCP_STATE_ESTABLISHED:' point.

4. a message displayed at the correct timeout at 'ptr_TCP->usLinkTimer' break.

5. after 1min 20 seconds a message appeared at 'case TCP_EVENT_CLOSED:' in callbank function on the socket in use.

Regards
Neil

[mark]

Hi Neil

Can you see which value ptr_TCP->usLinkTimer has in fnPollTCP()? It should start at your idle timer value and count down until the link times out (once a second). Since it is taking 80s to time out rather than the 10 that you set there is something wrong.

a) can it be that the 1s timer is much too slow - fnPollTCP() enters only once every 8s?
b) can it be that you have several sockets for reception on this port but have only set one of these to 10s timeout (each socket has its own timeout value)? Then the chance is good that the connection is using a different socket to the one that you have set the timeout to and this a different idle timeout.

Regards

Mark

[neil]

Hi Mark,
 I get the value of the ptr_TCP->usLinkTimer sent through the serial port, so I can see the value and frequency of the update.
It starts with the correct value when the connection is made, and counts down to 1 and stops. Then after about a minute or so the callback function for the socket gets called at 'case TCP_EVENT_CLOSED'.

I only have an outgoing connection, no listning sockets setup.

Neil

[mark]

Hi Neil

In the document \Documents\uTasker-TCP.PDF you will see the way that TCP connections close.

An active close (I think that this is the case that you have) passes through the FIN WAIT-2 state, which waits for the peer to respond with a FIN to the close sequence. If the peer doesn't respond (eg PC has been turned off or its socket has been disabled and it also doen't respond with a RST) it can in fact cause a socket to get stuck in this state forever.

For this reason the uTasker TCP/IP stack has an additional timer which is set to 60s (see TCP_FIN_WAIT_2_TIMEOUT in tcpip.h).
I could imaging that in your case the timeout is closing but the PC is not responding. This would then cause the 10s + 60s delay before the socket finally completely closes.
Note that according to the TCP specification the socket would never actually timeout and so would be blocked (theoretically) for ever. I think that most implementations do however have some timeout to stop resources being lost due to this over a long periods of time.

If this is the explanation, you may like to reduce the timeout TCP_FIN_WAIT_2_TIMEOUT to a shorter value so that the complete delay from the idle timeout to the close event is more exact.

Regards

Mark

[neil]

Hi mark,
  Thanks for the reply. 70 seconds is okay. My software also closes the connection if there is no reply after 'x' seconds, but I wanted to make sure that there wasnt a problem with the tcp connections, as i expected it to close in 20 seconds.

Regards
Neil

[oneFranck]

3. a message displayed twice at 'case TCP_STATE_ESTABLISHED:' point.

I'm also experiencing that. When a connection is established on my ColdFire eval board (52259 and 5282) it seems that the event TCP_EVENT_CONNECTED is called twice as I can see 2 messages "TCP Connection established" on the hyperterminal.

Code: [Select]

    switch (ucEvent) {
    case TCP_EVENT_CONREQ:
    fnDebugMsg("TCP Connection request received\r\n");                                           
    case TCP_EVENT_CONNECTED:
    fnDebugMsg("TCP Connection established\r\n");
    break;
    case TCP_EVENT_CLOSE:
    fnDebugMsg("TCP Connection stop request\r\n");
    break;   

Is it normal?

Francois

[mark]

Hi Francois

It is possibly because there is no break after the
        fnDebugMsg("TCP Connection request received\r\n");   

Regards

Mark