The tool should connect to any two TCP/IP servers and transparently route sends and receives between them. The tool should connect to both the TCP/IP servers and transparently forward any data it receives between the two.
The problem that the tool is intended to solve is that there are two networked devices, each behaving as a server. One of the devices will send TCP/IP data to its client when an event occurs on it, then other expects this data to be sent to it.
NOTE: Answer is completely revised based upon clarifications.
OP has two servers, both listening. One sends out data, the other is waiting for it to come in. But they are both listeners, and require a TCP/IP client to connect to both of them at the same time.
You need, essentially, a pipe program, that connects to both of the servers at the same time, and whatever is sent out of one server should be sent to the other.
Checkout the netcat program (Windows version available here). You might be able to do something like this:
nc <send svr> <send svr port> | nc <recv svr> <recv svr port>
Servers running TCP/IP can already communicate freely, assuming they're on the same net. That's what TCP/IP does. You might need to hook up a router of some sort if they're on different nets. If that's your issue, you need to describe your problem more fully, because what might be good for connecting isolated nets might not be good for subnets using NAT with a single IP address.
By mentioning "server" and "client", you seem to be implying some sort of application that communicates with TCP. However, many programs have distinct client and server roles that are not interchangeable. A Subversion server will not check out a source tree, for example. There is no automatic translation, and can't be, since people keep writing new programs. If you have a specific application, or list, in mind, you could add that to your question.
Based on the revised text, "You need, essentially, a pipe program, that connects to both of the servers at the same time, and whatever is sent out of one socket should be put into the other.", this sounds to me like a load balancer. And for this, you might actually look at load balancing / failover hardware. And this kind of connection is best managed by hard-ware based devices.
