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 services to choose from. The advantage of using a 3rd party file hosting service: HUGE scalability at very little cost ... probably cheaper than your internal costs of maintaining an FTP server. Using Stephen's worst case example of 500 world-wide clients all requesting an update 'simultaneously (across timezones<g>?)' ... not a problem. > 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 BTW: I enjoyed your detailed response. Congrats on such a successful project!!! Malcolm _______________________________________________ Post Messages to: [email protected] 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.
