Regarding sending/receiving files: Files are just text, so its the same as sending/receiving text, provided your own programs are handling both the sending & receiving.
the only thing that is different is that files are generally longer than short text messages, so you may want to send them in chunks, so that a progress report can be shown.
If you break a file into chunks, you'd have to have a method of the receiver knowing when the file will end (and, if a progress bar, it needs to know how much is coming).
So, you could invent your own, simple, protocol for sending files, that cooperates with the rest of your use of the connection, (for short text messages). after each message, the server should respond with a confirmation (say, "OK"

Something like:
SENDING FILE "File Name.ext" (means, I'm going to send a file"
--OK (represents response from server
FILE CHKSUM 111111 (provides the server a method for ensuring the file is intact)
FILE LENGTH 123456 (means, there are this many bytes in the file)
--OK
DATA CHUNK 0,1234,2222 (means, sending a chunk of data, starting at byte 0, this chunk is 1234 bytes long, and has check sum 2222. Including the start byte makes it possible for the server to ask for different sections. Including the checksum lets the server validate the chunk is intact.)
--OK
DATA CHUNK 1235,1234,2222
--RESEND CHUNK 2001 (server is asking for a chunk again starting at 2001)
DATA CHUNK 2001,1234,2323
--OK
etc.
Either side could cancel the send, say with CANCEL. when the file is complete, it should be obvious to both ends. If the file is smaller than 16MB, you can simply use FILETOSTR() and STRTOFILE() to read/write it to disk on each end.
The checksums are great for debugging the program: In use they shouldn't be very important because TCP handles error correction for you. The checksums can also help identify if the connection was dropped before the packets were completly sent.