Hello
I am trying to find code or document about downloading files with c for windows. But I can not find. Ca you help me? How can I downoad a file with C for windows programming?

Generally you click on the link labeled Download. Other than that you need to be more specific about what you want and what you are trying to do.

__________________

Cow: You're a lawyer too?
Mooseblood (mosquito): Ma'am, I was already a bloodsucking parasite. All I needed was a briefcase!

I want to write a program which downloads the file which is entered by the user. This can be txt file or jpg,bmp etc. I want to find the size of the file and then divide the download operation in to processes. Then main process will combines all file parts to make the file.(For example a txt file is 2400bytes)I have 6 processes .Each process download 400byte then main process will combine this to make the true txt file whoses size is 2400bytes.

I don't know what you're trying to accomplish by using the term "download," but it implies that you mean to get some file via an HTTP or FTP request through some server. In other words, each "request" to grab a file will result in the whole file and not some portion of the file.

If you "own" the server as well as the client, then you can thread the download into sections, but on a 2400 byte file, it is very likely not going to be worthwhile to try to D/L it using 6 threads much less 6 processes as the overhead (not to mention the cost on the server side) is going to be unthinkable.

If you are thinking of implementing a multi-threaded protocol that chunks down a file of some arbitrary minimum size (to account for diminishing returns) on both a server and client kind of ownership, then you probably will want to consider any number of existing protocols as examples of what to do/not to do for your own direction.

If you want to "read" a file from some arbitrary file system using multiple threads, you will likely find that a few problems exist if you need the "whole" file as the result of your work. First may be any issues related to the operating system and file locking or concurrent access to the file. Second may be the cost of identifying "chunks" of the file for each thread and the reassembly of the file once its related "cargo" packets are stored. Third may be the implication of the networking overhead associated with multiple threads pulling at portions of the same file versus a single thread pulling start-to-finish at the file. Given the potential for collisions, it suggests that there may be no real benefit to be gained by separating the file download into chunks even if the operating system overhead is not a factor. In other words, it is unlikely (in the case of a single file with single "user" access) that multiple threads acting against the file will ever be more efficient than a single thread acting against it. Forth is the consideration of how the server side is deployed and what, if any, cost/performance trade-offs might be compared to "conventional" file handling.

Given your example, the cost associated with starting 6 processes is greater than the amount of data in the 2400 byte file. There is no practical benefit. Even if the file is 24 MB or 24 GB, the question becomes one of what "server" is going to support a method of chunking a portion of the file, which is really "random access" to the file contents. If we assume an underlying protocol such as NFS, we're still likely to find that the increased network overhead of the multiple processes/threads will not favorably enhance the throughput of the file "download."

Of course, I'm assuming that something benign such as enhancing throughput is your goal, so I'm addressing this from that perspective. Since you indicate that "Windows" is your operating system choice for this endeavor, then I can definitely say that multiple processes for chunking a 2400 byte file is going to net a negative return on investment. If it is simply an exercise in file manipulation that you seek, then perhaps it is of some mild interest to pursue it for the benefits of education. Otherwise, I'd be contented to let a single thread access the file until "download" is completed and then, perhaps, use multiple threads to do any relevant work on the resultant file.


:davis:

2400 Bytes is only a sample it can be 10 MB or bigger or smaller. This is not important. I make the download operation by multi threads ,so each thread download some part of the file. Then the main process or thread will combine,integrate them to build the really file.

You really don't get it, do you? What "download service provider" is going to provide multithreaded "chunking" of a file based on multiple random access pointers into the file? What operating systems are going to support it?

Let's clarify what in the world you mean by "download?" Do you mean some web-based service? Do you mean some PC-to-PC interaction via come common networking methods such as Ethernet and TCP/IP?

Okay, let's open a socket connection to some remote (or local, it doesn't matter) host. The socket is going to be a single "pipeline" of data once read. What are you going to do, open multiple sockets to get access to different "chunks" of the same file?

Let's talk about how such a protocol would be implemented. Let's say that you connect on a "command" port, we'll arbitrarily use 2080 for now.

Request: connect 2080
Response: connected
Request: locate (filename)
Response: file (filename) available
Request: chunks (filename)
Response: file (filename) contains (number) chunks
...create (number) threads
...open (number) socket connections to (host)
...read (socket) (chunk)
Response(s): chunk (number) completed [successful, failed/reason]

How is this any better than simply opening a socket and requesting that the file be transfered? I can imagine that for a system where the individual socket connection is "throttled" (bandwidth limited) that a "multiple chunks" protocol would be beneficial, but what would prompt the "provider" to ever support the protocol?! And, if there is any "intelligence" to the throttling, then it will be based on the connection originator's addressing and then the chunking method won't be useful anyway.

I think that perhaps you are not realizing some basic networking intrinsyc such as the notion that a single socket connection "should" provide maximum throughput to a single file "resource" given the level of congestion/traffic on the network.

There are a lot of UDP-based protocols that basically stream data in what may appear similarly to a multi-threaded manner, but there is no benefit to be derived from threading multiple requests for a portion of a file UNLESS multiple networking topologies are involved. In other words, let's say that a particular computer "server" has five network interface cards (NICs). Let's say that a particular computer "client" also has five NICs. We will naturally assume that all 10 NICs in the "network" have unique IP addresses. If we somehow write a protocol that establishes streams on all 5 request channels then we can assume that the "download" will happen much more quickly than a single stream over a single channel. In this "configuration" we "know" a lot about the networking topology and we can exploit it...whether it truly represents any real gain in performance or not. However, as a "general" medium protocol, there are no "known" relationships that we can exploit. In other words, we don't know where the host we're connecting to has a hundred fiber channel NICs or a serial connection at 120 baud. I'm not suggesting that a protocol can't be developed that enumerates the capabilities of various network interfaces and exploits them appropriately, but who is going to be adopting it, should it be developed? Will an ISP be more interested in pushing a file down in the quickest possible time? ...or will the ISP be more interested in maximizing total available bandwidth across a wide variety of client connections, possibly numbering in the tens of thousands?

Let's say that the entire world adopts the "m-threaded protocol" RFC that we're discussing...and web servers around the globe decide to implement the protocol and support it. How many "clients" are going to have multiple Internet topologies that will truly support an "optimized" download?

In other words, unless you're trying to gain some benefit over multiple network channels, there isn't any real benefit to be gained by "threading" the notion of chunking a single file.

However, to be fair, maybe I'm missing something. Please feel free to elaborate as much as you possibly can.


:davis: