Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Jul 2006 16:47:39 +0100 (BST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Stefan Bethke <stb@lassitu.de>
Cc:        rizzo@icir.org, Mikhail Teterin <mi+mx@aldan.algebra.com>, net@freebsd.org
Subject:   Re: using ipfw seems to interfere with socket communication
Message-ID:  <20060702164232.G67344@fledge.watson.org>
In-Reply-To: <7024797F-62A3-43C0-A119-50A3DD34B279@lassitu.de>
References:  <200606271813.29980.mi%2Bmx@aldan.algebra.com> <7024797F-62A3-43C0-A119-50A3DD34B279@lassitu.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2 Jul 2006, Stefan Bethke wrote:

> 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.

With TCP (and UDP), the ability to immediately deliver has never been 
guaranteed due to socket buffer and window limits, scheduling priority, etc. 
TCP over the loopback interface really is TCP -- data is broken up into 
segments, wrapped in TCP/IP headers, processed by the firewall and dummynet, 
etc.  UNIX domain sockets should be used if it's desirable to avoid this, as 
that implementation delivers directly to the remote socket buffer.  However, 
due to socket buffer sizing and scheduling, blocking is possible there also. 
Stream sockets do not guarantee message boundary atomicity or immediate 
delivery, especially in the presence of SMP.

Robert N M Watson
Computer Laboratory
University of Cambridge



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060702164232.G67344>