From owner-freebsd-questions@FreeBSD.ORG Mon Sep 15 06:44:48 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 625D07FA; Mon, 15 Sep 2014 06:44:48 +0000 (UTC) Received: from mail.tivas.info (85.234.217.139.static.edpnet.net [85.234.217.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E6D48208; Mon, 15 Sep 2014 06:44:46 +0000 (UTC) Received: from localhost.localdomain ([192.168.3.104]) by mail.tivas.info (8.14.4/8.14.4) with ESMTP id s8F6igrL035580; Mon, 15 Sep 2014 08:44:42 +0200 (CEST) (envelope-from bram@diomedia.be) Message-ID: <54168ADA.6050204@diomedia.be> Date: Mon, 15 Sep 2014 08:44:42 +0200 From: Bram Van Steenlandt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: adrian@freebsd.org Subject: Re: Listen queue guestion References: <5415EC27.40708@diomedia.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 06:44:48 -0000 Hi, I use python, here the parameters are (socket.AF_UNIX,socket.SOCK_STREAM) Bram op 14-09-14 23:05, Adrian Chadd schreef: > Hi! > > What kind of sockets is it specifically using? > > > -a > > > On 14 September 2014 12:27, Bram Van Steenlandt wrote: >> Hi, >> >> I'm porting an plc automation system to freebsd and while doing so I got >> errors like these: >> sonewconn: pcb 0xfffff8000cecc870: Listen queue overflow: 76 already in >> queue awaiting acceptance >> >> With the help of netstat I've found the problem, 2 programs communicate with >> ipc file like sockets and the "client" was connecting too fast (it was >> connecting and disconnecting in a small for loop). >> >> Still, on linux this worked and there will be cases where I may bump in to >> this limit again (a lot of different programs communicate with one master >> program over ipc). >> >> I've found kern.ipc.somaxconn but this seems to be only for TCP connections. >> >> Is there a sysctl or kernel parameter that allows me to set this queue a bit >> larger ? >> >> Thx >> Bram >> >> _______________________________________________ >> 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" > _______________________________________________ > 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"