sendfile() in tftpd?
Hello, Would it be possible to use sendfile in tftpd? With an Athlon XP 1600+ I could only get ~40 Mbps out from the machine with 0% idle CPU time (large file transfers from many machines, getting the same file). Thanks, [ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]--- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Attila Nagy wrote: Would it be possible to use sendfile in tftpd? With an Athlon XP 1600+ I could only get ~40 Mbps out from the machine with 0% idle CPU time (large file transfers from many machines, getting the same file). Only if all file transfers were binary, or all ASCII files were stored on the host with CRLF line termination, instead of LF. That's the same reason sendfile() is stupid for POP3, IMAP4, and SMTP servers... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
AN Would it be possible to use sendfile in tftpd? AN With an Athlon XP 1600+ I could only get ~40 Mbps out from the machine AN with 0% idle CPU time (large file transfers from many machines, getting AN the same file). No, sendfile() is only for TCP connections, TFTP is using UDP. If you want performance, use something else. -Tomas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Hello,
Only if all file transfers were binary, or all ASCII files were stored
on the host with CRLF line termination, instead of LF. That's the
same reason sendfile() is stupid for POP3, IMAP4, and SMTP servers...
Hmm. Both FTP and TFTP supports ASCII and binary transfers, am I right?
In libexec/ftpd this case is handled this way:
case TYPE_A:
while ((c = getc(instr)) != EOF) {
[...]
case TYPE_L:
[...]
while (err != -1 filesize 0) {
err = sendfile(filefd, netfd, offset, 0,
(struct sf_hdtr *) NULL, cnt, 0);
[...]
As far as I can determine.
In libexec/tftpd there is also a similar possibility to handle each case,
because there is netascii and octet.
We have a lab here with machines, which have NICs with built-in bootrom
(Intel PRO/100) and run bpbatch (http://www.bpbatch.org/). During the
startup the user gets a nice menu from which he/she can choose the OS
(various Windows versions for the education and Linux). After this the
program checks the image on the harddisk and if it fails it gets from the
network.
And that's what isn't too good. One client can achieve about 15 Mbps but
if more than 10 (usually 20-30) clients want to fetch the images the TFTP
server first slows down (it eats all the CPU of the server, which is a
fast AthlonXP 1600+) then times out.
I think this could be improved if TFTP could use sendfile().
(I have a busy FTP server and I know how much sendfile() can speed up
things)
The main question here seems to be: could sendfile() be used with UDP, or
it is just for TCP?
BTW, the bpbatch stuff uses binary transfer (according to tcpdump
output)...
[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]---
Attila Nagy e-mail: [EMAIL PROTECTED]
Free Software Network (FSN.HU)phone @work: +361 210 1415 (194)
cell.: +3630 306 6758
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Hello, No, sendfile() is only for TCP connections, TFTP is using UDP. If you want performance, use something else. It's even in the manpage: Sendfile() sends a regular file specified by descriptor fd out a stream socket specified by descriptor s. Silly me. BTW, I can't use anything else. Are there any alternatives to TFTP for booting machines off the network? (using standard, PC components) Thanks! [ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]--- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
i've had this modified tftpd for some time now, o - it's single threaded - runs as daemon and does not fork new children o - it caches files o - uses mmap o - knows about some of the newer tftp stuff - mainly blocksize. it's been running for some years now, and lately i re-vamped it a bit to run under FreeBSD. ftp://ftp.cs.huji.ac.il/users/danny/tftpd enjoy, danny To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Tue, Apr 23, 2002 at 12:29:03PM +0200, Attila Nagy wrote: Hello, Would it be possible to use sendfile in tftpd? With an Athlon XP 1600+ I could only get ~40 Mbps out from the machine with 0% idle CPU time (large file transfers from many machines, getting the same file). Performance and tftp don't really go together. The server sends a part of a file, waits for an ack, sends the next piece, waits for an ack, etc. -- Ben An art scene of delight I created this to be ... -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Hello, i've had this modified tftpd for some time now, o - it's single threaded - runs as daemon and does not fork new children Basically, I don't have any problems with the inetd startup. It can be rate limited, etc. o - it caches files How? Doesn't leaving this job to the OS a smarter idea? o - knows about some of the newer tftp stuff - mainly blocksize. I think it's implemented in FreeBSD's tftpd too. (I can get 750 MB images with TFTP easily). My impression about this stuff: compiled and started on an up-to-date FreeBSD STABLE BOX (AthlonXP 1600+, 512MB DDR, two Intel PRO/100 with FEC) The lab consists of 733 MHz Celerons with Intel PRO/100 and 128MB RAM. The switch is a HP4000M. With the FreeBSD tftpd I could only get around 40 Mbps out of this box, the CPU usage was 100%. One client could fetch the stuff with an average speed of 14-15 Mbps. I could stay at this speed with 4-5 machines, fetching the images, after this count the bandwidth usage decreased per machine. With Danny's tftpd I could get 16-17 Mbps with one machine (this is what the client says) and around 4 Mbps per client at a concurrency of 24 machines. That's about 90-96 Mbps. I will try do more benchmarks with an accurate method, once I could figure out what should I use to measure the outgoing traffic to specific IP addresses (a /24 subnet)... BTW, FreeBSD's tftpd doesn't drop connections once it built up, while there are some problems with Danny's implementation in this area, but I am sure that this will be solved very soon. [ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]--- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Tue, 23 Apr 2002, Attila Nagy wrote: Hello, No, sendfile() is only for TCP connections, TFTP is using UDP. If you want performance, use something else. It's even in the manpage: Sendfile() sends a regular file specified by descriptor fd out a stream socket specified by descriptor s. Silly me. BTW, I can't use anything else. Are there any alternatives to TFTP for booting machines off the network? (using standard, PC components) Multicast! BootIX (nee InCom) have support for this in their BootROMS. it might not be hard to hack into Etherboot et al. Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Wed, 24 Apr 2002, Richard Sharpe wrote: Multicast! BootIX (nee InCom) have support for this in their BootROMS. it might not be hard to hack into Etherboot et al. bproc now uses multicast for distributing new kernels and init ram disks, if you want to see an example. It's on sourceforge. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Attila Nagy wrote:
Only if all file transfers were binary, or all ASCII files were stored
on the host with CRLF line termination, instead of LF. That's the
same reason sendfile() is stupid for POP3, IMAP4, and SMTP servers...
Hmm. Both FTP and TFTP supports ASCII and binary transfers, am I right?
TFTP... sendfile() doesn't work with UDP, anyway.
But anyway... by definition, sendfile can't do the requisite end of
line terminator conversion (CR fro Macintosh, LF for UNIX, CRLF
for Windows/MS-DOS) for FTP/TFTP, and it can't do the end of line
conversion for message stores or mail transfer (SMTP, POP3, and IMAP4
all specify that lines *shall* be terminated by CRLF).
In libexec/ftpd this case is handled this way:
case TYPE_A:
while ((c = getc(instr)) != EOF) {
[...]
case TYPE_L:
[...]
while (err != -1 filesize 0) {
err = sendfile(filefd, netfd, offset, 0,
(struct sf_hdtr *) NULL, cnt, 0);
[...]
As far as I can determine.
Yep. Wouldn't it be nice if it always worked, instead of only
working for binary?
In libexec/tftpd there is also a similar possibility to handle each case,
because there is netascii and octet.
Yeah, but the UDP lets it out, anyway.
[ ... TFTP booting ... ]
And that's what isn't too good. One client can achieve about 15 Mbps but
if more than 10 (usually 20-30) clients want to fetch the images the TFTP
server first slows down (it eats all the CPU of the server, which is a
fast AthlonXP 1600+) then times out.
The answer is probably boot a small image, and use NFS for the
real data, so you don't have to use UDP for the bulk of the data
you have to transfer.
I think this could be improved if TFTP could use sendfile().
(I have a busy FTP server and I know how much sendfile() can speed up
things)
FTP is TCP, not UDP. TFTP magically implements session state
(retransmit/retry) on top of UDP. In other words, it basically
implements the stream delivery you would get with TCP, in user space.
The main question here seems to be: could sendfile() be used with UDP, or
it is just for TCP?
It could probably be used. The retransmits, though, really need
to be built into the protocol, so it's pretty useless for UDP, if
ever you drop a signle packet, since you won't be able to recover.
You would have to implement the code for it.
Probably, the best idea, if you insist on it, is to implement the
TFTP retransmit/acknowledge for the reliable data delivery in the
kernel... as a stream protocol layer on top of UDP. And then
implement sendfile on top of that.
BTW, the bpbatch stuff uses binary transfer (according to tcpdump
output)...
All that means is that you won't have to do data conversion in
that particular case.
UDP datagrams don't really have a window acknowledgement (UDP
datagram delivery is, by definition, unreliable), so you can't
really self-clock the buffer size on the receiver to ensure that
you don't have to do retransmits. You *might* be able to get
around this with the TFTP as a protocol layer hack, but the
window size is one packet, so you're not really going to see a
significant speed improvement, after all the hacking is said and
done. Maybe 12%.
The main win of sendfile() at all is in not eating the window fill
latency by going back to user space, when using sendfile() with
TCP; actually, the overhead savings for using sendfile() can be
had without using sendfile(), for the most port, since the window
is generally large enough and the consumption slow enough that you
end up disk-bound on the sender, or ack-paced by the receiver's
inability to drain the buffer quickly, so you only ever see two
round trip latencies over the whole data stream.
For UDP, you're going to see the round trip latency for each packet
for the individual ACK's, so you're pretty much screwed from the
start, if you use a non-wondowed protocol like TFTP over UDP, at all.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Attila Nagy wrote: With Danny's tftpd I could get 16-17 Mbps with one machine (this is what the client says) and around 4 Mbps per client at a concurrency of 24 machines. That's about 90-96 Mbps. I will try do more benchmarks with an accurate method, once I could figure out what should I use to measure the outgoing traffic to specific IP addresses (a /24 subnet)... The main thing you will see is that the mmap'ed file pages will be LRU'ed out. Unfortunately, there is not one instance per client. You might do well to madvise() the file, as well, based on the expectation of having multiple sequential transfers of the same data. This assumes that you use the same boot image for each machine, which is advisable (IMO). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Tue, Apr 23, 2002 at 11:46:34AM -0600, Nate Williams wrote: No, sendfile() is only for TCP connections, TFTP is using UDP. If you want performance, use something else. It's even in the manpage: Sendfile() sends a regular file specified by descriptor fd out a stream socket specified by descriptor s. Silly me. BTW, I can't use anything else. Are there any alternatives to TFTP for booting machines off the network? (using standard, PC components) USE TFTP to get a tiny image up, and then go TCP. There are also lightweight TCP stacks that fit in 8K or 16K; you could come up with your own protocol, or decide to use FTP instead of TFTP for the download. In general, the faster you get to something TCP based, the happier you will be, so if you *must* use TFTP, then make the boot image really, really small. Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wirless. :( tftp in particular probably won't, because it uses the same packet window concept as TCP, but with the window set to 1. It is a protocol that is braindead by design, in order to be simple to implement. It was never pretended that performance was a design goal. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
[ TFTP performance is poor ] USE TFTP to get a tiny image up, and then go TCP. Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wirless. :( tftp in particular probably won't, because it uses the same packet window concept as TCP, but with the window set to 1. Actually, it still tends to kick TCP's butt in very lossy networks, because or resends and other vaguaries of TCP. We've done benchmarks, and when packet loss gets bad, TCP backoff algorithm (which causes window size shrinkage *and* increases in resend delays) cause TCP to slow to a crawl. We've found that TFTP's timeouts tend to work better, although it may be more an issue of having the lower overhead vs. TCP. It is a protocol that is braindead by design, in order to be simple to implement. It was never pretended that performance was a design goal. Completely agreed on that point. Another point worth mentioning is that it's rather trivial to add in some extensions to TFTP (that are backwards compatible) to speed it up by increasing the window size to even 2 packets. We were able to do that and it almost halved the transfer times. :) 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. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Nate Williams wrote: Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wirless. :( THat's true. I can't really think of an example of such a medium, though, that you would still trust to netboot something. 8-). Maybe 802.11b. 8-(. The specific problem here is that UDP is ``too slow''; it looks like a classic Doctor, it hurts when I do this 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wireless. :( THat's true. I can't really think of an example of such a medium, though, that you would still trust to netboot something. 8-). Maybe 802.11b. 8-(. Exactly! Or, something that boots remotely over satellite (for easier maintenance). The specific problem here is that UDP is ``too slow''; it looks like a classic Doctor, it hurts when I do this 8-) 8-). Actually, UDP is actually *faster* than TCP in these sorts of environments, if you know what you are doing. :) :) :) :) Overhead during a demo of my former company was demo'ing a product to a client, while the client was talking to our competitor. 'Hmm, how come your product doesn't do anything, when their product seems to be working fine here.'. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
Nate Williams wrote: Maybe 802.11b. 8-(. Exactly! Or, something that boots remotely over satellite (for easier maintenance). Or cable modems, booting from the cable plant. Actually, there's a lot of uses, the more you think about it, even though I think you'd have to be pretty insane to let someone dictate what software you run in your network access device. I guess cell phone users put up with it, though... it looks like Verizon and Qualcomm and a couple of others are now writing their contracts so they can download new crap to your phone and rearrrange your menus without your permission, or make you have to scroll through an advertisement before you can dial, etc.. I just keep thinking of some jerk on my cable segment responding to the boot me request, and proxying to the real cable plant. 8-(. The specific problem here is that UDP is ``too slow''; it looks like a classic Doctor, it hurts when I do this 8-) 8-). Actually, UDP is actually *faster* than TCP in these sorts of environments, if you know what you are doing. :) :) :) :) Overhead during a demo of my former company was demo'ing a product to a client, while the client was talking to our competitor. 'Hmm, how come your product doesn't do anything, when their product seems to be working fine here.'. 8-) 8-). I love that when that happens... Um, uh, er -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
On Tue, Apr 23, 2002 at 12:34:24PM -0600, Nate Williams wrote: [ TFTP performance is poor ] USE TFTP to get a tiny image up, and then go TCP. Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wirless. :( tftp in particular probably won't, because it uses the same packet window concept as TCP, but with the window set to 1. Actually, it still tends to kick TCP's butt in very lossy networks, because or resends and other vaguaries of TCP. We've done benchmarks, and when packet loss gets bad, TCP backoff algorithm (which causes window size shrinkage *and* increases in resend delays) cause TCP to slow to a crawl. We've found that TFTP's timeouts tend to work better, although it may be more an issue of having the lower overhead vs. TCP. This is an issue with TCP in your situation. You're playing with network equipment TCP wasn't designed for, and noticing that TCP isn't anywhere near perfect. It's relatively simple (see OSI before you disagree...), and optimized for common network technology at the time it was designed. (And sometimes those optimizations work...) There are things it doesn't fit well. A connection-less reliable datagram protocol might have been a better choice for http, for example. It is a protocol that is braindead by design, in order to be simple to implement. It was never pretended that performance was a design goal. Completely agreed on that point. Another point worth mentioning is that it's rather trivial to add in some extensions to TFTP (that are backwards compatible) to speed it up by increasing the window size to even 2 packets. We were able to do that and it almost halved the transfer times. :) Probably true, but the better solution is to find something else (or make something else) that doesn't completely suck like TFTP does. 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. Maybe a module for netgraph that does some retransmit handshaking optimized for your particular needs. ---Nathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
[ TFTP performance is poor ] USE TFTP to get a tiny image up, and then go TCP. Going to TCP soon assumes that you have a lossless medium in order to transmit packets over. If you're using a lossy medium, TFTP (and other UDP based protocols) can kick their butt because of TCP's assumption that packet loss is a function of congestion, which is often not the case in lossy mediums such as wirless. :( tftp in particular probably won't, because it uses the same packet window concept as TCP, but with the window set to 1. Actually, it still tends to kick TCP's butt in very lossy networks, because or resends and other vaguaries of TCP. We've done benchmarks, and when packet loss gets bad, TCP backoff algorithm (which causes window size shrinkage *and* increases in resend delays) cause TCP to slow to a crawl. We've found that TFTP's timeouts tend to work better, although it may be more an issue of having the lower overhead vs. TCP. This is an issue with TCP in your situation. You're playing with network equipment TCP wasn't designed for, and noticing that TCP isn't anywhere near perfect. It's relatively simple (see OSI before you disagree...), and optimized for common network technology at the time it was designed. (And sometimes those optimizations work...) Yer' preachin to the choir here. :) There are things it doesn't fit well. A connection-less reliable datagram protocol might have been a better choice for http, for example. You mean like TTCP? Unfortunately, it wasn't available, and because of inertia, it will probably never happen. :( It is a protocol that is braindead by design, in order to be simple to implement. It was never pretended that performance was a design goal. Completely agreed on that point. Another point worth mentioning is that it's rather trivial to add in some extensions to TFTP (that are backwards compatible) to speed it up by increasing the window size to even 2 packets. We were able to do that and it almost halved the transfer times. :) 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. :) 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. :) 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. 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... Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
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 [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendfile() in tftpd?
[ 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 [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
