----- Original Message ----- From: "Bill Moran" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 01, 2006 12:21 PM Subject: Re: Reducing the timeout on a TCP connection
> In response to "Ted Mittelstaedt" <[EMAIL PROTECTED]>: > > > This is why the snmp protocol uses UDP, Bill. > > > > You need to use something other than TCP for > > monitoring. > > Well ... if I'm monitoring a server that uses TCP (PostgreSQL) I can't > rightly establish whether or not it's successfully accepting connections > unless I used TCP as well. > Then you absolutely don't want to change TCP timeouts because none of the clients are going to be running modified TCP timeouts, and if your timeout-modified system can connect, that does not tell you if a client running normal timeouts can also connect. > I understand where you're coming from, but I can't see how I can use > UDP to solve my problem. > check the system for if it's there or not with udp, if it is there, then check for availability of the sql listener port. Ted > If I have to go back to management and say, "I can't get tighter > granularity than 90s" then that's what I have to do. I'm just trying > to do my research before I make that claim. > > In the long run, it's possible that I'll have to put together some sort > of client/server monitoring model that has a component on each system, > so that I have tighter control over things, but this initial version > is required "right now", so I have to make do the best I can, then come > back and improve it when there's time (probably over the next several > months). If I were trying to make it perfect, I wouldn't have started > with PHP ;). I'm using PHP because the development cycle is very fast. > This gets me my "quick and dirty" solution, then I can take a little > time to look into how to really do it right. I'm just trying to > establish exactly how "dirty" it's going to be. > > Thanks for the input. > > > ----- Original Message ----- > > From: "Bill Moran" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, August 01, 2006 12:02 PM > > Subject: Reducing the timeout on a TCP connection > > > > > > > > > > I'm writing some monitoring scripts, and I'm having some trouble because > > > the TCP seems to wait 90 seconds before giving up on initiating a > > > connection. > > > > > > (The script is in PHP, testing a PostgreSQL database. Neither PHP nor > > > libpq (which PHP's PostgreSQL support is based on) seem to have any > > > settings that can be used to adjust this timeout). > > > > > > If my memory of Stevens is correct, this is something that's set at the > > > OS level. It doesn't seem as if it's a configurable value, however. > > > I guess I'm looking for confirmation on that point first. If that's > > > the case, then I'll have to adjust my approach based on that knowledge. > > > > > > If it can be adjusted, can it be adjusted on a per-connection basis? I > > > don't want to mess with timeouts on other sockets, _just_ this one > > > monitoring script. > > > > > > And of course, the final question: how would I adjust this setting if > > > it's possible? If it's a sysctl, I'm missing it ... > > > > > > Suggestions? > > > > > > -- > > > Bill Moran > > > Collaborative Fusion Inc. > > > _______________________________________________ > > > freebsd-questions@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > > To unsubscribe, send any mail to > > "[EMAIL PROTECTED]" > > > > > > > > -- > Bill Moran > Collaborative Fusion Inc. > > **************************************************************** > IMPORTANT: This message contains confidential information and is > intended only for the individual named. If the reader of this > message is not an intended recipient (or the individual > responsible for the delivery of this message to an intended > recipient), please be advised that any re-use, dissemination, > distribution or copying of this message is prohibited. Please > notify the sender immediately by e-mail if you have received > this e-mail by mistake and delete this e-mail from your system. > E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. The > sender therefore does not accept liability for any errors or > omissions in the contents of this message, which arise as a > result of e-mail transmission. > **************************************************************** > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"