Innocence
The verdict on TCP is... not guilty. Suppose that shouldn't come as a surprise. We ran the system for one hour, and I compared the VmspClient message logs. There were a lot of them - during the one hour period, Wallisdown made and lost thirty-two connections to the server, which can be grouped into twenty-two distinct periods of downtime, the shortest of which was about five seconds, and the longest being about three minutes. As should be expected, the logs were identical, except for the end of each outgoing log, which had two more messages than the corresponding incoming log - these are the reconnection attempts. Every packet up to the connection loss was received intact.
So, somewhere between VmspClient receiving the message, Core.Connection giving it out, and the application actually acting on it, things are going wrong. I think there's little doubt that the reason is the way I am passing the messages around. This means a rewrite of the Connection and ServerConnection classes, and a redesign of the server architecture. Thankfully, all the server's business logic is in a separate assembly and not tied to the server itself in any way, so all that can remain unchanged. The changes I made to the server seem to have helped a lot, though I have managed to introduce a condition where it decides to stop processing any more requests. I think this is due to the way I have used the thread pool, but up until this condition occurs, it seems much more reliable.
Back to work!
So, somewhere between VmspClient receiving the message, Core.Connection giving it out, and the application actually acting on it, things are going wrong. I think there's little doubt that the reason is the way I am passing the messages around. This means a rewrite of the Connection and ServerConnection classes, and a redesign of the server architecture. Thankfully, all the server's business logic is in a separate assembly and not tied to the server itself in any way, so all that can remain unchanged. The changes I made to the server seem to have helped a lot, though I have managed to introduce a condition where it decides to stop processing any more requests. I think this is due to the way I have used the thread pool, but up until this condition occurs, it seems much more reliable.
Back to work!