CODEWITHSUNDEEP
c++unit-testingtcptimeout
Amey Jah
Amey Jah

Reputation: 913

How to test connect timeout on RHEL c/cpp application

I have an application which talks to server over HTTP. I have written a code to control connect timeout (amount of time it will wait before server replies) . But I am finding it hard to generate a test case to test my connect timeout code. Could you please help me.

Basically, TCp handshake will contain Host A sends a TCP SYNchronize packet to Host B

Host B receives A's SYN

Host B sends a SYNchronize-ACKnowledgement

Host A receives B's SYN-ACK

Host A sends ACKnowledge

Host B receives ACK. TCP socket connection is ESTABLISHED.

In my application, if server does not complete TCP handshek in x seconds, applications moves to next server. But to test this code, I need a server stub which will probably accept SYN packet from client but will not set SYN+ACK packet to client. Thus making client wait for server's reply.

Could you please help me to create small server stub which will listen to particular port but will not complete handshake.

Upvotes: 1

Views: 464

Answers (2)

philant
philant

Reputation: 35816

I wouldn't rely on iptables, or any other tool for unit testing, as those tests would be too brittle. What if the IP address changes, or the unit tests are run on another machine ? What if the code has to be ported on an OS where iptables is not available ?

In order to keep the unit tests isolated from the network, I would encapsulate the socket API in a Socket class. Then I would have a Connection class that uses the Socket class. I would unit test the Connection class with a TimeoutSocket class (derived from Socket) that simulates the server not accepting the first connection request.

Your code should not depend on what's going on on the wire.

Upvotes: 1

Flexo - Save the data dump
Flexo - Save the data dump

Reputation: 88711

Given you mentioned RHEL I think you're best off using iptables to help test this. For example you could call:

iptables -I INPUT -s hostb -d hosta -p tcp --dport $port --tcp-flags SYN,ACK SYN,ACK -j DROP

calling that before running the test (or even during it perhaps?) and an equivalent matched -X to delete it seems to be by far the simplest way of breaking a handshake halfway through.

Drop all SYN+ACK (warning, WILL break new SSH connections):

iptables -I INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -j DROP

Drop all from or to 10.10.22.34:

iptables -I INPUT -s 10.10.22.34 -j DROP
iptables -I OUTPUT -d 10.10.22.34 -j DROP

Personally I would use the most specific match you can possibly write to avoid accidentally breaking remote access or anything else at the same time.

You could get fancier and use the -m owner match to only apply this rule for packets to/from the UID you run this test as.

Upvotes: 2

Related Questions