Actions
Forum Thread Details
  • State Not Answered
  • Replies 3 replies
  • Subscribers 311 subscribers
  • Views 550 views
  • Users 0 members are here
Related

TCP server on zedboard shuts down after some interval

Former Member

Hello,

I have created a LWIP TCP server on the zedboard and a TCP client on MATLAB on the host computer(zedboard and host computer are connected over ethernet). The client requests the connection to the server, SYN, SYNACK and ACK packets are delivered successfully and the connection is established. (Packets are monitored on wireshark on the host computer).

 

Now, If the client keeps sending the data continuously to the server, then server receives the data and process them. BUT the server crashes if I take some time interval in sending the data. For example: If I send data from client to server at time 0, and I take a gap of 60 seconds and then try to send the data from client to server, then by this time the TCP server has crashed and it does not receive data.

If I keep sending data continuously then it does not crash, but if I take some time sending the next data, then TCP crashes.

 

can anyone suggest where I am going wrong 

I have been looking over the Internet to find solutions but any help/suggestions would be appreciated.

Thanks

  • 0

    Hi

    It is likely you are getting a TCP 'timeout' on the connection.

    I would suggest that if you are going to have extended periods where you are not sending data, make sure that the connection is closed by the client then re-opened when you need to send data again. Or take a close look at your software to see if there is a way that the server can break the connection. The reason for the server 'shut down' will be an if statement, where for example in the FreeRTOS+Lwip application that ships with Xilinx SDK for the Echo server;

    /* break if client closed connection */
    if (n <= 0)
    break;
     
    The above line will break the loop when nothing can be read from the incoming buffer, as 'n' is bytes read. The software assumes the client has closed the connection therefore returns to listening for a new connection. Without seeing your C code it is hard to give a definite answer.
     
    If this is a case, and you need to handle a pause in data, I would suggest that you remove the offending code and replace it with a suitable handle for timeout or closing the connection.
     
    Feel free to post a snippet of C code and I can have a look.
     
    All the best.
  • 0 in reply to Former Member

    Thanks for the help.

    I have 3 functions in this code:

    1. start tcp application.

    2. Connection accept callback

    3. Data receive call back.

     

    Here is the actual C code:

     
    int start_application()
    {
    struct tcp_pcb *pcb;
    err_t err;
    unsigned port = 1004;
     
    /* create new TCP PCB structure */
    pcb = tcp_new();
    if (!pcb) {
    xil_printf("Error creating PCB. Out of Memory\n\r");
    return -1;
    }
     
    /* bind to specified @port */
    err = tcp_bind(pcb, IP_ADDR_ANY, port);
    if (err != ERR_OK) {
    xil_printf("Unable to bind to port %d: err = %d\n\r", port, err);
    return -2;
    }
     
    /* we do not need any arguments to callback functions */
    tcp_arg(pcb, NULL);
     
    /* listen for connections */
    pcb = tcp_listen(pcb);
    if (!pcb) {
    xil_printf("Out of memory while tcp_listen\n\r");
    return -3;
    }
     
    /* specify callback to use for incoming connections */
    tcp_accept(pcb, accept_callback);
     
    xil_printf("TCP echo server started @ port %d\n\r", port);
     
    return 0;
    }
     
     
     
      err_t accept_callback(void *arg, struct tcp_pcb *newpcb, err_t err)
      {
      static int connection = 1;
       
      /* set the receive callback for this connection */
      tcp_recv(newpcb, recv_callback);
       
      /* just use an integer number indicating the connection id as the
        callback argument */
      tcp_arg(newpcb, (void*)connection);
       
      /* increment for subsequent accepted connections */
      connection++;
       
      return ERR_OK;
      }
       
       
       
     
       err_t recv_callback(void *arg, struct tcp_pcb *tpcb,
     
                                      struct pbuf *p, err_t err)
     
       {
     
        
     
       /* do not read the packet if we are not in ESTABLISHED state */
     
       if (!p) {
     
       tcp_close(tpcb);
     
       tcp_recv(tpcb, NULL);
     
       return ERR_OK;
     
       }
     
       // Receiving data in a buffer
     
        
     
       pbuf_free(p);
     
       return ERR_OK;
     
       }

    Although the option you suggested about client closing the connection and reopening again when it wants to send data, sounds good.

    But, my application needs server to push some data to the client when it is connected, so if I close the connection it would not be a very good option.

    It would be great of you if you could suggest something on the connected client. 

    Thanks for the help.

  • 0

    I can't see anything in your code which would break the connection on the client, unless the recv_callback is used when you are not in the established state, in which case you will be freeing the pbuf, which will likely terminate the connection.

    I have most experience with sockets and RTOS, I would recommend looking into it if your application is going to include more than a couple of network functions, all reasoning here: https://www.xilinx.com/video/soc/networking-with-lwip-focused-free-rtos.html

    As for the TCP Keep Alive, I would read this source to gain the understanding and use a packet sniffer program, such as Wireshark, to see why the connection is closed and by which end. That way you will be able to see where the issue is.

    http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html

    A potentially easier 'high level' fix could be to make the client send a random packet periodically when no streaming is necessary, this could be used as a 'keep alive' to the TCP connection.

    Please note, I cannot be held responsible for any software installation that may or may not cause damage to the installed location. The installation of software is under discretion of the user and with the IT administrators permission.