I think there are some classes in .net which wrap wininet which is a windows api which supports ftp and a few other things.
-----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Chad Osgood Sent: Friday, March 25, 2005 6:17 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Bulk data transfer of xml-based data: Best methods Another con for using FTP: No native facilities in .NET to complete the transfer. This third-party (unless you write it yourself of course, but I'm assuming that's not the approach you wish to take) dependency might be another cause for concern. If your file were ~30MB instead of ~3MB I would probably go with something like FTP, but given its relatively small size I would likely just compress the XML fragments before sending them across the wire; those in receipt of the message would then decompress it, reconstitute the tree (or whatever it is you're doing with it), etc. I had reasonable success with this method when using XML as the data object marshalled across process boundaries (pre.NET). You could use SharpZipLib [1] to compress. Anyway, just a thought. Kind regards, Chad [1] http://www.icsharpcode.net/OpenSource/SharpZipLib/Default.aspx On Fri, 25 Mar 2005 07:44:18 -0500, Bill Bassler <[EMAIL PROTECTED]> wrote: > I have a requirement to download fairly sizable blocks of xml (~3 MB) to > externally located client pcs machines(across the Internet). The received > data will then be persisted to a small client side database by a local VB6 > application. Plus, for some client sites, this amount of data would need to > be moved across dial up lines. I'm trying to determine the most robust, > most efficient and easiest to deploy and maintain method (in that order of > importance) to accomplish this. > > Some methods that I've considered are: > > Direct download request from a web method. > Pros > 1. Easy to do. > > 2.Web services interfaces are already available to potentially expose ways > to get at the data. > > Cons > 1. Potentially less efficient transfer mechanism to FTP? I don't know. > > Web service attachment file. > Pros - > 1. We're currently using web services to message data between disparate > applications quite a bit within the existing applications so there's at > least some web services interfaces already available to potentially expose > ways to get at the data. > > 2. Don't have to open port 21. > > Cons - > 1. Not sure of the actual status of the spec for WS-Attachment. i.e. I see > something about it possibly being obsolete and more about a spec called > Swa. It's confusing. > > 2. Not sure of the client-side requirements to extract the WS-Attachment > when received. Can the file easily be extracted by a VB6 application? > > 3. Potentially less efficient transfer mechanism to FTP? I don't know. > > File FTP'd > Pros - > 1. I assume an efficient data tranfer mechanism. > 2. Simple client side data read operation to get at the data. > > Cons - > 1. Need to open port 21. > 2. There are a bunch of files left on the client machine that need to be > locally managed. > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at http://discuss.develop.com > =================================== This list is hosted by DevelopMentorR http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor� http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
