From owner-freebsd-net@FreeBSD.ORG Sun Jul 2 11:31:57 2006 Return-Path: X-Original-To: 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 67D2A16A416 for ; Sun, 2 Jul 2006 11:31:57 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [213.238.47.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 645EE44465 for ; Sun, 2 Jul 2006 11:31:55 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.7/8.13.7) with ESMTP id k62BVQqx071390 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 2 Jul 2006 13:31:37 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <200606271813.29980.mi+mx@aldan.algebra.com> References: <200606271813.29980.mi+mx@aldan.algebra.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7024797F-62A3-43C0-A119-50A3DD34B279@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Sun, 2 Jul 2006 13:30:56 +0200 To: Mikhail Teterin X-Mailer: Apple Mail (2.752.2) Cc: rizzo@icir.org, net@freebsd.org Subject: Re: using ipfw seems to interfere with socket communication 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: Sun, 02 Jul 2006 11:31:57 -0000 Am 28.06.2006 um 00:13 schrieb Mikhail Teterin: > fconfigure $sock -blocking 0 > lappend result c:[gets $sock] > > was always returning empty string, instead of the string "two", > that was > written into the socket and flushed. > > Is the test wrong, and such result is possible, or is dummynet > triggering a > bug? Unloading the dummynet module allows the test to succeed... The test is wrong. See recvfrom(2), which the gets will eventually invoke: If no messages are available at the socket, the receive call waits for a message to arrive, unless the socket is nonblocking (see fcntl (2)) in which case the value -1 is returned and the external variable errno set to EAGAIN. And Tcl gets(n): If end of file occurs while scanning for an end of line, the command returns whatever input is available up to the end of file. If chan- nelId is in nonblocking mode and there is not a full line of input available, the command returns an empty string and does not consume any input. If varName is specified and an empty string is returned in var- Name because of end-of-file or because of insufficient data in non- blocking mode, then the return count is -1. Note that if varName is not specified then the end-of-file and no-full-line-available cases can produce the same results as if there were an input line consisting only of the end-of-line character(s). Essentially, dummynet delays processing of that "two" line just long enough to break the code's assumption that TCP over the loopback interface is instantaneous. If my fading memory of TCP/IP Illustrated Vol 2 serves me right, that was actually the case at least back then: the sendto system call would push the data all the way down to lo0, which would immediately pass it back up until it ended up in the receiving socket buffer. Dummynet will queue the packet, regardless, so it won't get delivered until the next time dummynet processes queues. In non-blocking mode, you must always be prepared to wait for data. Stefan -- Stefan Bethke Fon +49 170 346 0140