There are basically two ways to do this:
Use a file separator character, and implement a mechanism for "escaping" the separator if it appears in the content of a file.
Send the length of the file before sending the file.
The first approach requires both the sending and receiving end to examine each byte of each file transmitted. The second approach is better, because it avoids this. However, it assumes that you can determine the length of the file before you send it ... which may not always be the case; e.g. if you are generating the files on the fly, writing them directly to the socket stream.
There is a variation on the second approach epitomized by HTTP's "chunk encoding" scheme. (Thanks @BalusC for reminding me.) This involves splitting the file and sending it as a sequence of "chunks" preceded by chunk sizes. This has two advantages compared to the "size + file" approach:
- The sender does not need to know the file size before hand.
- It is possible (given suitable protocol design) for either the send or receiver to cancel/skip sending of one file and continue with the next one. (With the simple "size + file" approach, the protocol cannot support this because the sender and receiver cannot resynchronize reliably.)