Date: Fri, 18 Feb 2005 14:38:35 +0000 From: Peter Edwards <peadar.edwards@gmail.com> To: Deomid Ryabkov <myself@rojer.pp.ru> Cc: freebsd-hackers@freebsd.org Subject: Re: occasional ECONNREFUSED when connect()ing. Message-ID: <34cb7c8405021806386fb874ee@mail.gmail.com> In-Reply-To: <4215EB31.8020107@rojer.pp.ru> References: <4215EB31.8020107@rojer.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 18 Feb 2005 16:18:41 +0300, Deomid Ryabkov <myself@rojer.pp.ru> wrote: > I have a strange case of occasional refused connect()'s. > The system is running 4.10-STABLE. > > This was originally reported by one of our developers. > The test script he provided is a simple Perl script that repeatedly > fetches an URL > from Apache running on this same server. > In the run of 2000 iterations, there are 5-10 random errors fetching the > URL. > After further investigation and digging, I uncovered the true cause of > the error: > connect() returning ECONNREFUSED. > To see if this was somehow related to Apache, I wrote my own simple > server that > accept()'s a connection, read()'s what supposed to be request and > write()'s a stereotypic reply, > thus resembling an HTTP request/reply conversation. > The number of sporadically occuring connect() errors has increased somewhat, > maybe due to quicker turnaround of my stub-server. > The question is - why do connections get refused at all? > I can think of no valid reasons... Here's one: In your stub server, what do you set the backlog to in the call to listen(2)? By the time you get the file descriptor for the new call from accept(), the kernel has already established the TCP/IP connection, and is maintaining state (ie, using resources) for it If you take a while dealing with this new call, (starting a thread, forking, or even processing the connection), then by the time you invoke accept() again, any number of clients may have attempted to connect to you, and the kernel needs to maintain state for every connection that has been requested. The backlog on the listen call indicates how many of these connections the kernel should hold on to: If the number of unaccept()ed connections reaches the backlog, you'll start to get ECONREFUSED errors at the client. If your stub server is single-threaded, this'll be pretty much guaranteed to happen if the number of clients exceeds the backlog on ths server's listening socket. HTH, peadar.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34cb7c8405021806386fb874ee>