#1
  1. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    95

    transferring files thru tcp/ip


    -ok, onto my next project, do something with tcp/ip clients/server. so i decided to do a fairly toned down P2P application. i've already got all the basics down of how clients will register at the server, and the server will link up clients seeking to transfer files. my question is, how are the files actually sent? i dont think that it would be in the same manner that messages are sent, i.e.:

    nBytesSent = send (hSocket, sendText, strlen(sendText) + 1, FLAG);

    or is it, and u just cast the file to a (char *)? does a separate port need to be opened, perhaps teh ftp one? need a lil push in the right direction...
  2. #2
  3. Banned ;)
    Devshed Supreme Being (6500+ posts)

    Join Date
    Nov 2001
    Location
    Woodland Hills, Los Angeles County, California, USA
    Posts
    9,594
    Rep Power
    4207
    It entirely depends on what application protocol you are using. You could always invent your own and send it down the same pipe that your message is sent.

    For example, if you wanted to send foo.txt (which happens to be 3249 bytes, for example) you could send:
    strcpy(buf, ""FILENAME: foo.txt 3249");
    send(hSocket, buf, strlen(buf), FLAG);
    nBytesSent = send (hSocket, sendText, strlen(sendText) + 1, FLAG);

    The other end, on reading the string FILENAME, would determine that you're sending a file that is called foo.txt and is 3249 bytes long. Hence it could read the next 3249 bytes and put them in foo.txt. This is a very simple protocol, but it only allows you to transfer one file at a time.

    Alternatively, you could open a second socket that listens for a connection, on a different port #. Then send a message via the first socket, specifying the port # of the newly listening socket. The client can then connect to the second port # and start receiving the data. Meanwhile, the first socket connection can be used to create/control more connections, so that you can transmit multiple files.

    It all depends on what you want to do. Hope this helps :)
  4. #3
  5. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,091
    Rep Power
    2222
    Usual disclaimer: I haven't tried this myself, so all I'm offering is feedback and some ideas and/or things to consider. I'm not speaking from experience, but rather from my theoretical understanding of the problem.

    Actually, you would send the file data as messages. TCP is the right choice, since you aren't as strictly restricted as to the packet size -- TCP is going to segment what you send anyway, then reassemble it at distant end, all transparent to your application.

    You might want to Google for a description of how FTP works to get some ideas. For one thing, FTP uses two connections: port 21 is the FTP control port and port 20 is the default data port.

    If you go with two tcp connections, then the control channel would pass the messages to set up the file transfer and to help coordinate the transfer itself -- eg, notify when the transfer would start, what the file name is, how many bytes to expect, notify when the transfer is complete, etc. The data transfer channel itself need not be opened until it's actually needed.

    If you go with just one tcp connection, then you could prepend a special header on the front of the data to let distant end know that this is a data transfer message and how much data to expect, etc.

    I would probably choose to buffer the file. I would create a one to 4 or 8 KB buffer, then loop, filling the buffer from the file and then sending the buffer contents to distant end. If there's handshaking involved (distant end sends back a data-request message which means that it has processed the data received and is now ready for more), then wait for the ACK/data-request and then fill and send the next buffer's worth.

    Does that sound like it makes sense?
  6. #4
  7. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    95
    well that's a relief, i was thinking that it would be much more complex than just sending a packet with the same format im used to. but now that i think about it, this makes sense, b/c after all no matter how it is setup it will always be traveling in a packet, i believe. i think the ftp idea might be a little too complex right now, but i will do some googling and see what i can learn.

    dwise<< the only part that confused me was the "breaking it up" part. i think by that u mean, reading each line of text from a file perhaps and sending line by line? but what about for say a mp3 or jpeg or etc... i'm aware that their are programs that can split up files into smaller pieces, but i couldn't fathom calling that from inside my program, that seems way out of my league!

    i think for now i will see if i can send a decent size text file w/o getting any errors using the regular send method. thanks for the help guys
  8. #5
  9. Contributing User
    Devshed Supreme Being (6500+ posts)

    Join Date
    Jan 2003
    Location
    USA
    Posts
    7,091
    Rep Power
    2222
    Originally posted by infamous41md
    dwise<< the only part that confused me was the "breaking it up" part. i think by that u mean, reading each line of text from a file perhaps and sending line by line? but what about for say a mp3 or jpeg or etc... i'm aware that their are programs that can split up files into smaller pieces, but i couldn't fathom calling that from inside my program, that seems way out of my league!
    Doesn't require anything fancy, just a little basic low-level I/O.

    Code:
        #define BUFSIZE  2048;   // 2 KB
        typedef unsigned char BYTE;
    
        BYTE buffer[BUFSIZE];
    
        int  fd = open("recData", O_RDONLY);
        int n;
    
        // when we read zero bytes, we have reached the end of the file.
        while ((n = read(fd, buffer, BUFSIZE)) > 0)
        {
            // send the n bytes of contents in buffer to distant end
        }
        // notify distant end of end of file.
        close(fd);
    And this even works in a C++ program -- I took the code from a C++ assignment we did for class.

    There might be some fstream way to do it too, but I'll not lose any sleep over it. I know that I need to learn STL, but I'm still unimpressed by iostreams.
    Last edited by dwise1_aol; April 24th, 2003 at 09:24 PM.
  10. #6
  11. No Profile Picture
    Junior Member
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2003
    Location
    New Zealand
    Posts
    28
    Rep Power
    0
    Yerp. I would create a struct containing the clients socket, request information and file handles.

    You have a big loop where you accept incoming connections, rx data from clients, process, and tx data.
  12. #7
  13. not a fan of fascism (n00b)
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Feb 2003
    Location
    ct
    Posts
    2,756
    Rep Power
    95
    heh, thanks for teh suggestions guys. i think this maybe my next next project. i decided to make a networked chess game for this one. i still want to do the p2p thing, but if i did it i would want to be really nice, not half ***, and i dont think i have enuf time to make it the way i want since its due in a couple weeks. that'll be my summer work i guess! :)

IMN logo majestic logo threadwatch logo seochat tools logo