From owner-freebsd-net@FreeBSD.ORG Sat Apr 8 06:48:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 51AF416A401 for ; Sat, 8 Apr 2006 06:48:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E36A43D45 for ; Sat, 8 Apr 2006 06:48:41 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 4A5E346B0C; Sat, 8 Apr 2006 02:48:41 -0400 (EDT) Date: Sat, 8 Apr 2006 07:48:41 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Qiao Yang In-Reply-To: Message-ID: <20060408074021.O40714@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Unreliable Unix Domain DGRAM socket? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 06:48:44 -0000 On Fri, 7 Apr 2006, Qiao Yang wrote: > Does anyone know what possible scenarios may cause the Unix Domain DGRAM > socket to lose packet? We know, in theory, it is unreliable, but in reality, > I rarely see packet loss happens to this type of socket. Unfortunately, I > believe it happened a few times in the last couple of months in a FreeBSD > 5.3 box and I wasn't able to track down what the cause was. > > One related question. Considering the following setup, client (socket_A) > send a packet to server (socket_B). If the sending buffer of socket_A is ok > but the receiving buffer of socket_B is full, will sendto() return error? Yes -- there are several situations where packets can be lost. The most typical one is that there is insufficient room in the receive buffer. uipc_usrreq.c:uipc_send() calls sbappendaddr_locked() to append to the remote receive socket: if (space > sbspace(sb)) return (0); uipc_send() converts this to ENOBUFS. Other loss scenarios include EMSGSIZE if the message is too large. If sendto() is called with the flag MSG_DONTWAIT, you can also get ENOBUFS due to mbuf allocator exhaustion. Robert N M Watson