Date: Tue, 23 Apr 2002 14:58:44 -0600 From: Nate Williams <nate@yogotech.com> To: utsl@quic.net Cc: Nate Williams <nate@yogotech.com>, chat@FreeBSD.ORG Subject: Re: sendfile() in tftpd? Message-ID: <15557.51972.914307.703315@caddis.yogotech.com> In-Reply-To: <20020423204622.GA23933@quic.net> References: <Pine.LNX.4.44.0204231521120.24266-100000@scribble.fsn.hu> <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> <20020423204622.GA23933@quic.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[ moved to -chat, since this has no business being in -hackers anymore ] > > > 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. No, it exists because it's good enough to do the job. It's not optimal, but it's good enough. Optimal for all situations means re-inventing TCP over and over again, which is non-optimal from an engineering point of view, IMO. > > > > 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? Because that is what IP does. IP's job is to route packets. No reliability, no streaming, no nothing. It just makes sure a packets gets from point A to point B. (See your ISO layering pictures and descriptions.) > 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. And your point is? > > 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. Yer preaching to the choir. It's *WAY* too much for *WAY* too little gain. On top of it, it's non-portable. > > 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. ??? It's my job to provide optimum solutions to my employer, using the least amount of both my resources and their resources. In other words, if we were in a perfect world, with no time schedules, and infinite resources, a perfect solution as you suggest might be a good idea. But, unfortunately (or fortunately, depending on your perspective), I have to work with what I got, since I've got a zillion others things to do besides trying to perfect a file transfer protocol that is used less than .01% of the time in the lifetime of the product. I'd rather spend my time optimizing the other 99.99% of the functionality of the product, since that's what most of my customer's are more concerned with. Some would call this good engineering, but apparently you aren't in that group. In another product at another company, I messed with perfecting a data transfer protocol that worked over wireless mediums. Like it or not, loss is not only common, it's considered acceptable. In that case, because of design considerations (it must run on legacy hardware running on legacy software, ie; any pc running any version of Win95/98), messing with device drivers is simply unfeasible. So, you work with what you got, which means a standard TCP/IP stack, with no additions. Amazingly enough, both products *work* despite all of the limitations. I know it might be hard for you to believe that one *can* provide a working solution without resorting to OS hacking, but it is not only possible, sometimes it's actually fun. :) Nate ps. I've done my share of kernel hacking, and my current job is *all* kernel hacking, but just because I have a hammer in my toolbox doesn't mean that every problem looks like a nail. :) :) :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15557.51972.914307.703315>