Hi All,

my client server application can work in two modes:
1) one direction - only client sends msgs to server
2) two directions - server gives 'answers' to client.

when program run in the first mode it looks OK, but when server answers to client than client's application exit its operation after a short while. I am trying to find the problem but have some taugh time.

this is the function that reads the data in the client side (in which I have problems):


after buffer (decodeUnifiedMsgForServer) is filled by the function above I decode the data into the relevant data classes as follows:


the first 3 bytes in the buffer are integers (general data such as - total len, msgID etc.) and I decode them in the 2nd function. afterwards I send the buffer into specific data classes that decode the relevant data they need using the fuction decodeMsg.

my questions are as follows:

1) why is the length of the buffer (decodeUnifiedMsgForServer) is always 0 and not equals to the length of the msg received from server? I know that the data is received from the server because it is logged correctly, but still when I check length of msg it equas 0 (first 'if' in second function) - any ideas?

2) when I remarked the line that calls the decodeMsg the application 'behaved' OK and client didn't exit its operation. I think that this error has something to do with memory leak. maybe if I understood the first question I could understand this one as well.

Thank you so much for your help,
Lenna

well, I don't know the answer to the first question but I probably found out the answer for the seconf one. the reason why the program got crazy is that since it's multi threading there's a situation where an event is raised which cause the system to freak out. I still haven't found why it freaks out but if I prevent the event to be raised than logging is OK and client application is not exit its operation.

I'll be happy though if someone could answer my first question above - why is the length of buffer = 0? could it be because I use memcpy in my encode/ decode buffer functions?

thanks again,
Lenna

Hello Lenna,

It is a complex application, and the problems could be at different places so use debugger to investigate the exact reason. Nevertheless I've made some code observations:

1. About "TCPClient::readSocketData"
if the remote side closes the socket for writing ( shutdown the socket ) or closes it.
then the function "recv" returns 0

see man recv
"The return value will be 0 when the peer has performed an orderly shutdown."

That method will exit at the second return because "br" will be 0 and the return value will be 0. So Any data at the buffer will be not touched at all.

I also recommend you to use errno and #include <errno.h> to check the error after each failed system call. I recomment you to check errors.

2. Have in mind that if you are testing both the client and the server at the same machine (localhost) exiting the client with unclosed socket causes the server to receive SIG_PIPE signal. So I recommend you to block that signal at the server.

3. The method "BrainControlComData::decodeMsg(char* decodeUnifiedMsgForServer)" has no idea about the buffer length.

char* is a pointer to a byte or byte sequence

I recomment you to change that declaration to

BrainControlComData::decodeMsg(const char* decodeUnifiedMsgForServer, size_t size )

That's why these lines looks strange:

if(strlen(decodeUnifiedMsgForServer) == 0)
{
char* error = "probably an error (see Q1 below)";
}


I suppose that decodeMsg simply does not get the buffer with correct length, And it does not make any checks about the correct length. It assumes that everything is OK, and when that is not true you get strange results.

The memcpy is not neccessary
int Web_lenOfClass;
// decode len of msg
memcpy(&Web_lenOfClass, msg, size);
int lenOfClass = ntohl(Web_lenOfClass);


You could replace it with:
int lenOfClass = ntohl( *(uint32_t*)msg );

and also
int msgID = ntohl( *(uint32_t*)(msg + MSG_ID_LOCATION ) );


4. If you have time I would recomend you to create unit tests ( test in isolation ) about each important class/methods. And to check them more carefully. More testing with more precise tests.


Best Regards
O.