At 10:13 AM 11/28/2006 -0500, Malcolm Greene wrote: >Charlie, > > > About the biggest bottleneck in our design is that initial startup when > the 'version' file is grabbed. But the file is generally under 3KB, and > since it's retrieved via FTP all the overhead/burden of HTTP, etc isn't > there. So the >only real limitation is the communication bandwidth. > >You might also consider a hosted download service like filekicker.com. I >am not endorsing filekicker - there are many filekicker.com like ... Well, this is a Federal Agency. So the issue of hosting elsewhere probably is a non-starter. And I mis-spoke a bit - I should have said "... the biggest PROBABLE bottleneck..." In all the years of operation, there has NEVER been an actual comms bottleneck with our system (but they have had bottleneck problems with web page stuff on other servers - but again, that wasn't a comms bottleneck problem). So we are not looking at ways to change that part of the design.
> > And from what I've seen, using the FTP approach is the most efficient > way to go. > >I've chosen HTTP vs. FTP for following reasons: > >1. no firewall issues with ftp port(s) >2. no passive vs. active ftp issues >3. secure if https used vs. http >4. http access can trigger a script for tracking update activity >5. http is simpler if you're just requesting files We've run into some of the things you mentioned above. Some are addressed by letting the users set some of the FTP options. We are also planning to add optional HTTP file transfer pretty soon. Mainly to be able to have 'secure' transmission (HTTPS) - but to date the data was considered public anyway so this hasn't been a priority. We do send files in both directions, so figuring out the right use of HTTP "post?" to send a file is still in the works. For most of the issues, we just documented the details and 99% of the users don't have problems. When discussing FTP with companies, it was educational (and very sad) to find out just how little most IT people really understood about how computers operate and what happens in a communication protocol (the MS dumb-down effect I suppose). There were some IT shops that actually said FTP insecure because it was so old. They were a little embarrassed to be told that TCP/IP was older than FTP and that it is being used whenever HTTP is invoked. There are SSL FTP options available, but IIS didn't have them (I think IIS 6 might?). By the way, you can set up logging on the FTP sites to track things if desired. We didn't though. I wish we would have - it would give us better estimates on the number of computers using our systems. We have it on now to just generally monitor things. But I disagree that HTTP is simpler than FTP for requesting files. It definitely was not several years ago. In our OCX component, we just specify the site, 'FTP directory', filename, and tell it to download the file. You can't get simpler than that. With HTTP you sometimes also have to worry about proxy settings, special authorized access passwords, etc. Also, in our testing, it was found HTTP took much longer to transfer files than FTP. Our files are generally pretty small (and generally compressed - .zip), but we didn't see the need to waste any bandwidth if we could help it. I'm curious, what HTTP 'components' do you use? Did you roll your own, or are you using WWWC's? A 3rd party? Do you have HTTP 'send' capability as well? -Charlie _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
