change solaris network timeout

I 开发者_高级运维need to have as quick timeout as I get (connection failed) on windows. but on solaris its much longer, how can I make it shorten? (I'm trying to connect on purpose to a machine that does not exist to simulate a machine is down).

When I'm performing this on windows --> timeout --> good

D:>telnet 192.168.23.21 222

Connecting To 192.168.23.21...Could not open connection to the host, on port 23:

Connect failed

D:>

on windows (the target ip does not exist) then in about 15 seconds the command terminates.

However when I perform this from a solaris --> very long timeout --> not good for my legacy code machine like this:

myuser@mycomp:~$ telnet 192.168.23.21 222

Trying 192.168.23.21...

Then the process does not terminate

and this has major implications for me because i'm migrating an app from windows to solaris, and I must be able to have this timeout (in legacy code which I cannot update), so I need at the OS level to control this timeout to be as short as is currently in windows. How can I change this timeout in my solaris OS then? to be short, just as I havbe it on windows

Thanks

---

If you absolutely have to do this systemwide, there's a TCP driver parameter tcp_ip_abort_cinterval that can be modified:

tcp_ip_abort_cinterval - This is the amount of time that a connection is allowed to stay in a half open state. This is 180,000 (3 minutes) by default. You can change this to 25,000 if you want (25 seconds). Please note that by changing this you may find that SLIP/PPP users may have problems conacting your site.

To view your current setting:

/usr/sbin/ndd /dev/tcp tcp_ip_abort_cinterval

To change the setting:

/usr/sbin/ndd -set /dev/tcp tcp_ip_abort_cinterval 25000

---

Perhaps you could set the socket option SO_SNDTIMEO -- that link reports Solaris doesn't respect that option, but you might be lucky and they've fixed it by now. :)

If the socket option doesn't work, you could always set an alarm(2) for some point in the future and interrupt your connect(2) call. It feels pretty gross, but it is an option.

Another option is to switch to non-blocking socket operations and poll at some point in the future if the connect(2) operation succeeded or not. You could see a timeout to select(2) and discover if it has errored or is readable/writable. (See also the EINPROGRESS bit in connect(2).)