0 Replies Latest reply on Oct 20, 2015 1:22 AM by sam.lin

    asynchronous problem in internal_netconn_tcp_server_socket_callback

    sam.lin

      Hi,

      In WICED/network/LwIP/WICED/tcpip.c:

      The implementation comparing remote_ip.addr && remote_port to determinate

      if the request is a new_peer or not.

      We have observed some cases that the checking got wrong result.

       

      The root cause is when got a zero length new_peer, current code sends

      WICED_TCP_CONNECT_CALLBACK_INDEX asynchronous event.

      Given the nature of asynchronous event we don't know when the other thread

      will finish handling the connect event, it's possible that next packet is coming

      before the code to handle previous CONNECT event.

      Thus the upcoming packets are run into wrong state.

       

      Normal case:

      1) zero_length packet -> new_peer: send CONNECT event

      2) non-zero length packet -> !new_peer (receive): send RECEIVE event

      3) zero length packet -> !new_peer (disconnect): send DISCONNECT event

       

      Wrong state case:

      1) zero_length packet -> new_peer: send CONNECT event ( but accept is not yet called or finished)

      2) non-zero length packet -> still new_peer (because another thread calling accept is not yet finished, remote_ip.addr/remote_port are not yet updated).

      3) zero_length packet -> if another thread calling accept is not yet finished it will still be new_peer, thus send CONNECT event again.