Date: Wed, 21 Sep 2005 14:35:41 +0200 From: =?ISO-8859-1?Q?Sten_Daniel_S=F8rsdal?= <lists@wm-access.no> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: UDP dont fragment bit Message-ID: <4331539D.9030204@wm-access.no> In-Reply-To: <20050921114511.D34322@fledge.watson.org> References: <20050918212110.61962.qmail@web54501.mail.yahoo.com> <20050920134408.Y34322@fledge.watson.org> <43313924.9050009@wm-access.no> <20050921114511.D34322@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote: > > So if someone could generate some application pseudo-code that suggests > what specifically is necessary from the socket layer in order for the > application to function, we can talk about socket service extensions > that might support the application. For example, a way to query > detailed error information rather than just the SO_ERROR socket option. > Or a longer haul PMTU data gathering mechanism for UDP sockets. Or ways > for UDP applications to more usefully query the kernel for the TCP PMTU > data already being recorded. > > It sounds like for the bandwidth tester, IP raw sockets already provide > what you need, since you want to be able to do fairly irregular UDP > things (i.e., receive UDP packets with bad checksums, and see fragments). > IP raw sockets? Sure, Everything can be solved the complicated way :o) Some userland applications could benefit from having the option of DF flag set/unset. What about applications that wants to have a way of optimizing UDP transfers in their network path? Some networks filter icmp and fragments irresponsibly (imho) and sometimes the combination of two or more networks that would cause problems for multicast/video/voip applications. Sometimes in one network udp packets need fragmenting and in the next network fragments need to get reassembled to pass a firewall which in turn runs out of reassembling resources. ( It is more common to block icmp messages about reassembly problems than DF problems IF a message is generated in the first place. ) Sure, all of this could be fixed the complicated way but what if one already has an application that runs in unprivileged userland. How many lines of code would a simple socket option plus the "tuning" code require? -- Sten Daniel Sørsdal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4331539D.9030204>