I've heard when trying to send a big file over sockets, it is common practice to 'break up' the file into smaller parts and then send those over _multiple_ sockets/TCP connection simultaneously. Does this really speed things up? I must mention that the kind of architecture I have in mind does not involve the server running multiple threads. I merely want one server socket on the server and multiple client sockets. Does this even make sense? This is part of a networks course assignment and I just don't see it happening without threads . Your input is appreciated.
I vote "no". When one is sending data across a network, one is constrained by the throughput of that network. Adding multiple streams of data would do nothing to improve throughput. As a matter of fact, by opening more than one socket you'd be increasing the overhead and congestion and would probably decrease throughput. Perhaps you are thinking about a protocol like Bittorrent where "swarms" of peers exchange different chunks of data at the same time?
Well I'm not quite sure. What I posted previously is based on the text of the assignment which is as follows:
The objective of this lab. is to get familiar with TCP/IP and its UNIX interface, and then build the skeleton of a very simple file transfer system. The system should allow you to experimentally determine the best way of transferring a large file.
Recall that some modern file transfer programs allow you parallel downloads. So in general, you can transfer a file by using m parallel downloads. In fact each of these downloads can be done in n sequential parts. Assuming each chunk to be of equal size, you will transfer mn chunks, each of size file_size/mn. The parameters m,n determine the transfer schedule. You are free to choose the part of the file being transferred in each of these chunks; e.g., you can transfer the first 1/m fraction of the file over the first connection, and so on.
Note: In general, parallel downloads can take place from more than one server. For this assignment you can just use one server.
You should write a client/server application that does the following.
* The concurrent server program runs waiting for a connection from a client. * The clients and the server should run on different machines. * Each client asks the user for the name (path) of a file, and the transfer parameters m,n defined above. It then opens m TCP connections to the server and transfers the chunks (as you defined them) over the connections. * Experiment with different m,n and provide guidelines (and rationale) for a good m,n that a user should use. * This is meant to be a simple program, you probably will need to impose some limitations; that is fine, just state them clearly. * You will lose points if your program does not close the sockets when the program quits. * In order to prevent two students from using the same socket number on the same machine, you should use the socket number that is 2000 + x/2, where x is the last 4 digits of your student number (take floors if needed). * You may use C/C++ or Java. Resources for network programming in either language are on the class page. * Check the class page for clarifications etc. * If this assignment piques your curiosity about P2P systems, you can see a very detailed tutorial here. We will cover some aspects of P2P systems later in the course.
Perhaps I'm not getting something or the requirements is not clear enough.
Originally posted by Maysam Sorkhabi: * If this assignment piques your curiosity about P2P systems, you can see a very detailed tutorial here. We will cover some aspects of P2P systems later in the course.
Sounds to me like your instructor is introducing the basic principles of P2P protocols like Bittorrent and FastTrack (both of which permit a client to download parts of a single file from multiple peers), but your exercise here isn't intended to exactly model the behavior or performance of them. Sockets and threads are not related, so there's no reason your server couldn't be single-threaded. If your instructor wants chunks transferred concurrently, you'll want to use a multithreaded server.
For a multi-threaded server wouldn't there be synchronization issues as to how the data received over each socket must be assembled to construct the original file being sent? From what I know, synchronizing threads for file access etc isn't exactly *simple*, a claim the posted exercise document makes. This was another reason of confusion for me.
I don't see your assignment making the claim that synchronization is difficult. Synchronizing multiple threads can cause headaches (see the Java Tutorial chapter on Concurrency for more). I don't think it would be a problem in this assignment because I don't see anything in the requirements that would raise a flag (i.e. deadlock, race conditions and so on).