I've been working on a prototype for a new piece of software which will add new functionality to our system. It is to be a proxy between an existing Win32 MFC app written by a different engineering group and our system which has functionality that they need. The MFC app could be anywhere on a network and our system can be anywhere else. So, the prototype needs to have the ability to be somewhere else entirely as well. The real trick is, the MFC app has to work with or without the proxy - the proxy has to be completely invisible to the MFC app.

So, I wrote a multi-threaded library that opens a socket and listens on that port for incoming connections. When a connection is made it handles the tcp stream and incoming byte arrays accordingly. It's configurable with an XML file to specify how many listeners to start and on which ports they're to listen on when it starts up. It listens on a given socket for incoming connections, when a connection is made it passes it to a worker thread that does some logging and forwards the tcp packets on to another waiting socket connected to our system on the back-end. I built-in a garbage collector to clean up the worker threads if client connections are dropped, and it's got a combination of asynchronous delegates and ThreadPool delegates to dump messages into MSMQ and raise events for client subscribers (e.g. a Console app or Windows Service) to trace events.

All-in-all it works pretty good, it's scalable, and it's pretty robust. But there's this one little bug that continues to drive me mad Mad MAD! I can't put my finger on it.

The method that does both the send and receive to the socket on the back-end is synchronized so only one client can forward packets at a time. Any other packets just queue until the back-end socket gets the bytes out of the receive buffer. For this particular application it makes it more robust since the system that the back-end connects to can't handle many connections. When the tcp packet reply is received on the back-end the first byte, or first two bytes specify the size of the incoming packet, that way I know how much to receive from the stream in case a number of packets are arriving at the same time. There is a concrete rule - there is a 1:1 relationship between messages and replies. Now there's the problem. Something is bunking up my receive buffer (sporadically) on the back-end. I believe the other system is broadcasting something as an additional response to the original message that isn't expected. Consequently, there are two results - It's unpredictable and it's insanely frustrating to debug!

Good night.