Robot Communication Part Two B - Threading
In order to provide the client and the server the zip file must be split into:
In Part One I placed the Socket Server in the controller and the Socket Client in the robot. In terms of C# framework, this provided full .NET for the Server and NETMF for the client. This seemed the natural way of establishing two-way communication especially as the server is the more complex side of the process. In Part Two, I have reversed this structure and placed the Socket Server in the robot and the Socket Client in the controller. In Part Three the plan is to introduce WinForms (a single threaded module) to the controller. Apparently the combination of WinForms and a Socket Server (a distributed threading module) is difficult to code, hence Part Three will attempt to add WinForms to the Client Socket code. Part Four, I hope, will add all the robot hardware related NETMF code.
The primary purpose of this stage of the project is to introduce multi-threading. I have used the same structure of four threads: receiving, sending, commands and data: in both the controller and the robot. Between each pair of threads a queue is used to help the transition between threads (see the attached diagram). This structure is a first time beginners guess. But be warned, with any multi-threaded program, it is best to thoroughly test the code before adding the threading.
Other than writing code for a Arduino Tank I have never programmed anything before. Please post any comments or suggestions about the design or code.