IP task on tracker side

The IP task on the tracker decides to connect to the controller. The controller is always waiting for the connection request passively. The tracker must always be connected to the controller. If the connection goes down, the tracker tries to establish it again until it succeeds or the tracker is stopped; the error message handling at tracker side is the following:
  • The error messages display is enabled at initialization time.
  • The error messages display is disabled after a TCP/IP connection problem (EQQIP15E or EQQIP17I are issued in the message log), so that the following connection retries will not issue error messages.
  • The error messages display is re-enabled when a connection is successful; an informational message informing about the restored connection is issued (EQQIP12I).

The IP task is always waiting for an event; iteration is done if the task receives an event.

The main events that the IP task can receive are:
  • There is work on the TIPQ.
  • There are bytes to be read on a socket (write() from controller).
  • Bytes are to be written on a socket (write() to controller).
  • A started task stop request must be processed.
  • The loop timeout has expired.
  • Task abnormal end.
When the IP task receives an event, it starts iterating and checks:
  1. Whether the loop timeout has expired or an abnormal end occurred.
  2. The reading sockets. If there are bytes to be received from controller, the IP task receives the bytes.

    If some buffer received is completed, the received information is checked: if this is a DQE from the controller, the task enqueues the information on the data router queue (RTRQ). If the connection to the controller is not established, the tracker tries to connect even if the loop timeout has expired.

  3. The task queue. If there is work on the TIPQ, the IP task stores the entries in another internal queue of the task for later processing.
  4. The write sockets to verify if there is a connection() or write() request pending for the controller that must be processed. The request result is checked.
  5. Whether there are entries in the internal queue. If there are, the IP task processes the DQE and sends the data to the remote trackers.