From owner-freebsd-arch Wed Mar 14 16: 1:55 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 6858837B71C for ; Wed, 14 Mar 2001 16:01:49 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.9.3/8.9.3) id QAA09211; Wed, 14 Mar 2001 16:47:51 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp04.primenet.com, id smtpdAAAz9aqYr; Wed Mar 14 16:47:34 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id QAA09476; Wed, 14 Mar 2001 16:53:24 -0700 (MST) From: Terry Lambert Message-Id: <200103142353.QAA09476@usr08.primenet.com> Subject: Re: [PATCH] add a SITE MD5 command to ftpd To: nate@yogotech.com Date: Wed, 14 Mar 2001 23:53:19 +0000 (GMT) Cc: dnelson@emsphone.com (Dan Nelson), des@ofug.org (Dag-Erling Smorgrav), freebsd-arch@FreeBSD.ORG In-Reply-To: <15023.61042.768406.854325@nomad.yogotech.com> from "Nate Williams" at Mar 14, 2001 03:19:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Another thing to consider before adding SITE MD5 as a command is that > > it's an extremely slow operation. md5'ing a 10MB file takes about > > 1/3rd of a second on my pIII/600. It would take 5 minutes of CPU time > > to md5 1-gig worth of sources, and that's assuming that the FTP server > > is idle. ftpd would have to cache the md5 checksum somewhere for it > > to be acceptable, and then you've got the same caching problem (how > > does ftpd know when the file has changed to is can update its cached > > md5?). > > Is that cost greater than the cost of sending the data out over the > wire? Depends; do we know any FTP servers that trumpet the number of users they are currently supporting, where the marketing benefit of a larger number of users exceeds the benefit of not sending useless files? Remember that the only thing this is useful for is files that change without changing the filename (e.g. no version number in the name, etc.). I'd argue that that was pretty rare. Personally, I like the "SIZE" suggesion. Not only that, it would allow a precomputation of estimated time to completion of a download of a set of files, and could also be used to provide a meaningful "percentage complete" or other progress indicator. Plus it's already there; it's just that the port's aren't storing it when they store the MD5, but that can be changed. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message