Date: Tue, 1 Aug 2006 13:09:11 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Bill Moran" <wmoran@collaborativefusion.com>, <questions@freebsd.org> Subject: Re: Reducing the timeout on a TCP connection Message-ID: <002901c6b5a6$5b07bc30$3c01a8c0@coolf89ea26645> References: <20060801150226.0c911297.wmoran@collaborativefusion.com><000401c6b59e$92d942d0$3c01a8c0@coolf89ea26645> <20060801152107.eba203fa.wmoran@collaborativefusion.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Bill Moran" <wmoran@collaborativefusion.com> To: <questions@freebsd.org> Sent: Tuesday, August 01, 2006 12:21 PM Subject: Re: Reducing the timeout on a TCP connection > In response to "Ted Mittelstaedt" <tedm@toybox.placo.com>: > > > 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" <wmoran@collaborativefusion.com> > > To: <questions@freebsd.org> > > 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 > > "freebsd-questions-unsubscribe@freebsd.org" > > > > > > > > -- > 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 "freebsd-questions-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002901c6b5a6$5b07bc30$3c01a8c0>