Question

I am working on a client-server project and need to implement a logic where I need to check whether I have received the last data over a TCP socket connection, before I proceed.
To make sure that I have received all the data , I am planning to pad a flag to the last packet sent.I had two options in mind as below and also related prob.

i. Use a struct as below and populate the vst_pad for the last packet sent and check the same on the recv side for its presence. The advantage over option two is that, I dont have to remove the flag from actual data before writing it to a file.Just check the first member of the struct

typedef struct
   {
    /* String holding padding for last packet when socket is changed */
    char vst_pad[10];
    /* Pointer to data being transmitted */
    char *vst_data;
    //unsigned char vst_data[1];
   } st_packetData;

The problem is I have to serialize the struct on every send call. Also I am not sure whether I will receive the entire struct over TCP in one recv call and so have to add logic/overhead to check this every time. I have implemented this so far but figured it later that stream based TCP may not guarantee to recv entire struct in one call.

ii. Use function like strncat to add that flag at the end to the last data being sent.

The prob is I have to check on every receive call either using regex functions or function like strstr for the presence of that flag and if so have to remove it from the data.

This application is going to be used for large data transfers and hence want to add minimal overhead on every send/recv/read/write call. Would really appreciate to know if there is a better option then the above two or any other option to check the receipt of last packet. The program is multithreaded.

Edit: I do not know the total size of file I am going to send, but I am sending fixed amount of data. That is fgets read until the size specified -1 or until a new line is encountered.

Answer 1

Do you know the size of the data in advance, and is it a requirement that you implement a end of message flag?

Because I would simplify the design, add a 4-byte header (assuming you’re not sending more than 4gb of data per message), that contains the expected size of the message.

Thus you parse out the first 4 bytes, calculate the size, then continue calling recv until you get that much data.

You’ll need to handle the case where your recv call gets data from the next message, and obviously error handling.

Another issue not raised with your 10byte pad solution is what happens if the actual message contains 10 zero bytes–assuming you’re padding it with zeros? You’d need to escape the 10bytes of zeros otherwise you may mistakenly truncate the message.

Using a fixed sized header and a known size value will alleviate this problem.