A course project for a system that can run on bare metal hardware that: (1) implements FM transmission decoding, (2) primitive TCP/IP stack, (3) primitive MySQL protocol, (4) stores audio part of transmission in MySQL database, (5) uses web services to decode audio speech into text and stores this into the database, and (6) provides a web based front-end to list, view, and play the stored data.
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.
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.
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