Its a very lightweight tool (written in Java) that acts as a middleman between the server and client. When I said this, you can obviously make out that this tool acts like a server (listening to port connections from the real client system), as well as client (sending/relaying the TCP packets that it received from client, to the server). This functionality seems very simple to implement and so, you can write a simple TCPMon for yourself, but there are couple of more things that you can do with ‘TCPMon’, which could be very useful when you are testing some ‘Web Applications’, ‘Webservices’ or ‘Client-Server Applications’, in general.
Below are some of the uses of ‘TCPMon’:
1) For checking/testing the TCP messages that flow between Client and Server systems.
2) ‘Resend’ option - which lets you resend any request that TCPMon got from client system (which is cached at TCPMon layer).
3) ‘Simulate Slow Connection’ - This is probably the best use of TCPMon, cause you can probably test the scenarios of ’slow connection speeds’ or ‘broken communications’.
4) TCPMon can also be setup, to act as a proxy.
Below is a schematic of how TCPMon is setup between client and server:
If you look at the pic, you can see that TCPMon sits in between server and client and just relays the TCP messages that it gets from the client and sends back the response to the client, if and when it receives a response from the server. This comes in handy to a developer, if he/she wants to check whats really happening and what TCP messages/packets are flowing between client and server.
I used this tool, out of my personal interest, when I was working on some client-server type application. I had this scenario, that a Client (mobile device with .Net technology) communicates with Server application (Java, Glasshfish Server,EJB, servlets, webservices, et al) and so, I wanted to check and also test the application in different ways (apart from the typical unit testing stuff). I changed the Glassfish server port (by changing the configuration in domain.xml) to 9090 (instead of 8080) and setup TCPMon as below, in the screenshot:
Once you configure and add the connection, TCPMon is listening to port 8080, for client connections. If you have a client, which is setup in such a way that it sends request to server on port 8080, it is transparent to you that there is TCPMon in between the server (real) and the client. Below is a screenshot of TCPMon, when it is active:
In the above pic, the big, bottom-left frame on TCPMon window is for displaying the ‘Requests’ received from Client and the right one for ‘Response’ received from the Server. And the rows with white background, at the top of the window show all the request-response messages/packets between the server. At the bottom of the window, you can also see the “Resend” button, which can be used to resend a particular request, thats been cached at TCPMon layer. Also, you can save those “Request-Response” messages or see them in XML form.
The functionality that was most useful for me was ‘Simulating Slow Connection Speeds’, since I was using a client (simulating mobile device client) written by me, which uses ‘Apache HttpClient’ framework. I tested with different scenarios and system passed through the tests, but gave me some ideas for tweaking up the system and also clear up some bug patterns. Here’s a screenshot, which shows how to setup the TCPMon, to simulate slow connections: