The TCP implementation is sending spurious ACK packets with a strange acknowledgement number. This can been seen after the socket has been opened and running for a small amount of time.

Possible Causes

• acknowledge packets may be generated in response to no external source
• acknowledge packets may be generated in response to an external source

For an external source, the acknowledgement packet may be generated in response to the reception of a packet that is wrongly decided as part of the connection (such as another connection on the wire).

The following checks should be performed:

• check packet filtering mechanism
  • ip source, ip destination, tcp source port, tcp destination port

The TcpSocketMessage serves as a dual purpose. It handles control and data messages to the system socket implementation, and it handles control and data messages from the system socket implementation.

The problem is that this dual purpose provides the opportunity for the manifestation of bugs in both code paths. The path to the system socket has to account for messages that may only ever be used coming from the system socket, therefore, the TcpSocketMessage type needs to be split into two seperate types.

This problem happened early in the design and development and was used for ergonomic reasons, but now that the code has matured it is realized that this ergonomic ease for development is no longer needed and simply hampers the prevention of bugs in future development.

The following tests or test sets are needed:

• MySQL Test Set
• TCP/IP Test Set
• Common Test Set _(For the common module.)

In the MySQL module the MySQLConnection::connstate and MySQLConnection::is_connected form a disjoint composite structure. They can become logically desynchronized manifesting bugs.

The working of connstate needs to be securely synchronized with the socket's connection state. If the MySQL connection state is set to Idle then the socket connection should be disconnected.

Make the test more comprehensive. It should do at least the following:

• validate the HTTP reply
• issue more requests on the same connection
• ensure that large requests happen in order to test stability of the connection
• create multiple connections (could be in seperate test such as test_net_tcp_http_multiple)

The current MySQL driver implementation is lacking types that are needed and will currently panic if it receives them. This is not suitable for deployment in a production environment.

The TCP socket user side object needs to produce a message that the connection has taken too long to happen. This may need to come from the system side of the socket, since the thread may be blocked for receiving on the user side socket channel.

The pending commands is a composite of two structures in the MySQLConnection.

The pending_cmds: Vec<PendingCommand> and pending_cmds_sent: u32 are both disjunct in their usage. This provides the potential for one to be adjusted without adjusting the other causing the manisfestation of a bug or critical failure of the MySQL system instance.

These functions need to be combined into one by providing a seperate structure that unifies these two type instances with methods.

The NIC interface should be abstracted from the Net system. At the moment the Net system uses PCAP and this should be abstracted so that anything could be used, and that which is used can be specified during the Net creation. This would facilitate the following goals:

• flexbility - allow usage of interfaces besides PCAP
• testing - allow usage of testing interfaces to perform more controlled intricate tests