From owner-freebsd-hackers Tue Apr 23 13:46:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from quic.net (romulus.quic.net [216.23.27.8]) by hub.freebsd.org (Postfix) with SMTP id 52DEC37B405 for ; Tue, 23 Apr 2002 13:46:15 -0700 (PDT) Received: (qmail 24210 invoked by uid 1032); 23 Apr 2002 20:46:22 -0000 From: utsl@quic.net Date: Tue, 23 Apr 2002 16:46:22 -0400 To: Nate Williams Cc: hackers@FreeBSD.ORG Subject: Re: sendfile() in tftpd? Message-ID: <20020423204622.GA23933@quic.net> References: <3CC59C44.13013A1E@mindspring.com> <15557.40442.852602.681416@caddis.yogotech.com> <20020423182839.GA22074@quic.net> <15557.43312.713502.540548@caddis.yogotech.com> <20020423195947.GA22950@quic.net> <15557.48900.773726.309492@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15557.48900.773726.309492@caddis.yogotech.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Apr 23, 2002 at 02:07:32PM -0600, Nate Williams wrote: > > Probably true, but the better solution is to find something else (or > > make something else) that doesn't completely suck like TFTP does. > > Because it's used so rarely, having it suck every once in a while isn't > so bad. TFTP is well supported natively in lots of hardware platforms, > so rather than re-inventing the wheel over and over again, we chose to > continue using what other vendors have used, but we 'optimized' it for > our situation. That's called 'good engineering' in my book. :) That's what everyone else said, and why that stupid protocol still exists. > > > However, it required slight modifications on the part of the sender, and > > > the ability to recognize when the double window size modification had to > > > be disabled because certain (very slow) pieces of hardware couldn't > > > handle even the slight speedup of packets. > > > > I suspect that you might be better off solving your lossy network issues > > with a layer under IP, rather than tinkering with the protocols that sit > > on top. > > Actually, I disagree. IP is all about routing, and since we still want > packets routed correctly, something on top of IP *is* the best > solution. (Check out your OSI model. :) Why should routing enter into it? Ethernet is a pretty mindless MAC layer, but there are others like PPP or Token Ring that aren't, and IP runs fine over them. LLC2 does something similar to what you'd need, although I don't think it'd be the right choice. > In any case, even writing my own 'RDP' (Reliable Datagram Protocol) on > top of IP was massive overkill. It means messing around with the stack > on every OS used in the product (which includes Windoze). Most of the > stacks are *NOT* written with extensibility in mind, even assuming you > can get your hands on the source code. On Windows, you could put that RDP layer into the network driver, and not mess with the rest of the network stack. Or, perhaps write a driver that sits between an existing network driver and the IP stack. I did something like that with DOS drivers once. > The amount of resources (both in terms of finding people with enough > expertise as well as the time to do proper testing) to do such a task is > beyond the scope of almost any hardware vendor. > > Been there, done that, only going to do it again if it makes sense... Sounds suspiciously like a problem with the standard for your medium. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message