From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 09:14:37 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6676C16A4CE for ; Tue, 6 Apr 2004 09:14:37 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C22D43D46 for ; Tue, 6 Apr 2004 09:14:37 -0700 (PDT) (envelope-from berhart@erhartgroup.com) Received: from cocaine.erhartgroup.com (c-67-166-0-138.client.comcast.net[67.166.0.138]) by comcast.net (rwcrmhc13) with SMTP id <20040406161413015003s386e>; Tue, 6 Apr 2004 16:14:14 +0000 Message-Id: <6.0.2.0.2.20040406100638.01c6f288@mx1.erhartgroup.com> X-Sender: berhart%erhartgroup.com@mx1.erhartgroup.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.2.0 Date: Tue, 06 Apr 2004 10:14:26 -0600 To: freebsd-net@freebsd.org From: Brandon Erhart Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: The Almighty KQueue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 16:14:37 -0000 Hi, I told you all I'd be back for more :) I am not sure if this is the most appropriate place to post this, but it seems that you all know what the hell you're talking about, so I figure you can help me out here. As I said in my previous post about the FIN_WAIT states, I am writing a web sucker downer (mirror). What I don't believe I mentioned before is that I am using the KQueue API in FreeBSD 4.9-REL to take care of watching over my sockets. I seem to be running into a nasty problem, however. Here's a scenario. I set the outgoing connections to, say, 5000. The problem is, the amount of connections my program shows as being connected is roughly 1/2 to sometimes even 1/8th of what is actually connected. I see what is "actually connected" by doing a netstat. The program would say 750/5000 connections, while a netstat would show 4500 connections in the ESTABLISHED state. You may be saying, "it must be a bug in your connection tracking logic". I honestly don't think that's it. I have only TWO places in my code where I check if the connection was successful (and therefore increasing the global connection counter) -- in the callback function for data read() from KQueue-monitored fds (all of the sockets), and then also in my main loop (I check for read, write and connect timeouts there, right after my call to kevent()). Basically the main loop looks like, in psuedo-code of course: while (there_is_still_events) { if (kevent()) <-- i pull one event from the kqueue { execute_the_callback_function; } check_for_read()_write()_and_connect()_timeouts; check_for_"client_descriptors(basically just a structure that holds info on the kqueue event)"_that_need_to_be_connected_to_the_next_server_and_do_so; } It's pretty straight forward. I have no idea why my program would be reporting a smaller amount. Is it possible that my program is not getting ALL the information it needs from kevent()? Perhaps the KQueue is becoming "full"? Is this possible? Should I be pulling more than one event off the kqueue at a time? I have been up ALL NIGHT trying to debug this, and cannot figure it out. Any and all help is appreciated! Thanks, Brandon