In the current code in the Ethernet drivers the command/response communication is done with a simple send(); recv(). This is not robust if there are any glitches in the communication.
The problem is that the application and the device can get "out of sync" such that the application receives the response to a previous command, rather than the response to the current command. This is easy to demonstrate with a simple application that is polling the device. If the Ethernet cable is unplugged for a few seconds the communication will get out of sync, with the wrong response being received for the last command sent. The application can never recover from this, and must be restarted. In the real world there are occasional brief network glitches, and this causes a problem for applications that must be very reliable.
There is an easy fix for this. The command/response communication is changed to flushInput(); send(); recv(). This flushes any stale input before sending the next command. I have implemented this as follows:
Added new flushInput() and sendMessage() functions to ethernet.h and ethernet.c. sendMessage() simply calls flushInput() and then send().
Changed all of the drivers to call sendMessage() rather than send().
With this fix I can now unplug the Ethernet cable while the application is running, and within a second or so of reconnecting the cable the application resumes with no problems.
flushInput() will not actually flush anything if the communication is working correctly. If it does flush any bytes it prints an error message so the user knows that there has been a communications glitch.
wjasper
commented
5 years ago
In the current code in the Ethernet drivers the command/response communication is done with a simple send(); recv(). This is not robust if there are any glitches in the communication.
The problem is that the application and the device can get "out of sync" such that the application receives the response to a previous command, rather than the response to the current command. This is easy to demonstrate with a simple application that is polling the device. If the Ethernet cable is unplugged for a few seconds the communication will get out of sync, with the wrong response being received for the last command sent. The application can never recover from this, and must be restarted. In the real world there are occasional brief network glitches, and this causes a problem for applications that must be very reliable.
There is an easy fix for this. The command/response communication is changed to flushInput(); send(); recv(). This flushes any stale input before sending the next command. I have implemented this as follows:
With this fix I can now unplug the Ethernet cable while the application is running, and within a second or so of reconnecting the cable the application resumes with no problems.
flushInput() will not actually flush anything if the communication is working correctly. If it does flush any bytes it prints an error message so the user knows that there has been a communications glitch.