variable timeout

Galen has asked for the wisdom of the Perl Monks concerning the following question:

I have some code that interacts with numerous network elements. I want to set up a variable timeout for these interactions, so that timeout is automatically increased when I am interacting with network elements that have high latency, and decreased for the reverse..... is this possible?

I imagine that I could ping the element before actually connecting to it, and then adjust the timeout value according to the results. However, it would be better if I could somehow measure the amount of time it takes to get back a login prompt when I first try to connect, then use that data to control how long I wait for a datastream to be returned to me after I issue a command to the element. Is it possible to set up some kind of timer for this situation?

My only other option is to set the timeout value to be so large that I never fail to receive data.

Comment on variable timeout

Replies are listed 'Best First'.
Re: variable timeout by AgentM (Curate) on Apr 18, 2001 at 02:21 UTC
You should consider leaving the default value of the socket timeout. Usually, it is best left alone unless you expect an extremely poor network connection. If you really need it, look at the SO_LINGER socket option. The initial receipt time (RTT-round trip time) of the packet in no way determines the RTT of the rest of the packets. Of course, if you insist on setting this, it is as simple as setting the SO_RCVTIMEO. Look at setsockopt. AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.	[reply]
Re: variable timeout by traveler (Parson) on Apr 18, 2001 at 02:32 UTC
I'm not sure what modules you're using, but if you are doing network I/O without any modules (and maybe if you are using some some modules) you can use timeout of 'select'. Set it to a small value the first time and count the number of times it times out without data. That will give you an idea of how long talking to a particular host takes. Then if it takes, say, 50 times longer than that in the future, you can report the condition or do whatever you plan on doing. traveler	[reply]
Re: Re: variable timeout by Galen (Beadle) on Apr 18, 2001 at 18:40 UTC
I should have clarified a little better exactly what I'm doing. I'm using Net::Telnet, IO::Select and IO::Pipe. As it turns out, changing timeout isn't fixing my problem after all. I've been testing the code on two elements that are local (ping time 8ms). It works perfectly on these two elements. When I ran a more rigorous test on 20 elements that are located 2000 miles away (ping time 80ms), I ran into problems. The data I received looked exactly like what I get if I time out waiting for a login prompt. However, this wasn't true for all 20 elements. The first 10 elements work fine, but data from the next 10 degrades more and more until I receive nothing at all from the 20th element. So, even though the results "look" like a timeout problem, this may not be the problem. The code uses fork() to connect to each network element on a selected list. I was interested to see what happened on the webserver when I ran my forking code, so I viewed "top" while executing it. If you aren't familiar with the Solaris command, "top" shows a dynamic list of currently running processes together with data on CPU time and memory usage. When I run my CGI script on two network elements, I see two processes pop up, and then disappear when the data has been gathered. If I do the same thing on 5 elements, I see 5 processes. If I try 20 elements, I see about 10 processes that hang around until the script thinks it is finished getting data from all 20 elements. This leads me to believe that the server has placed some kind of internal limit on child processes in order to prevent overload. This is good, as I was planning on setting a limit anyway. I believe what I'll do is to calculate the number of forks necessary up front, and do them in batches of 5. It'll take longer to get the work done, but as long as I don't close the HTML page while I'm getting data, the user may begin viewing output from the first set right away.	[reply]
Re: variable timeout by Galen (Beadle) on Apr 18, 2001 at 02:20 UTC
Hmm I just thought of something. It shouldn't be that hard to just do a system call to current time twice and subtract the two.	[reply]

Back to Seekers of Perl Wisdom

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.