Racing the Stack in C++

[ipndrmath]

First let me preface this by saying that I am, unfortunately, working on a close sourced project. Because of this any code that I can supply would be fairly specific and short. I wish I could release the code, one in support of open source, and two, I know it would be beneficial to answering my question, but at this time, my company has decided to remain close source.

Background:

Developing a client - server application communicating over TCP. Therefor, I an using the normal send() and recv() functions. Additionally, packet payloads are encrypted with a custom algorithm. Commands are sent to the server, but the server does not execute the commands immediately, but stores them in a string array and executes them after the socket is closed (Few exceptions).

Program Information:
Linux sockets
g++
Currently single threaded (This will change)

Problem:

When the client is finished communicating with the server it sends a specific command that is essentially a " I am done, will you send me the commands that you received and the hashed values of each command" packet. When the server receives this command (This is one of the exceptions), it sends the list of commands that it received in one packet followed by the hashes in another packet. On the client side, the client notes that the "finish" command has been sent and blocks with recv(). It receives the first packet, in this case the list of commands, and then blocks with yet another recv() [ Note: I currently have this in a loop, but it doesn't work either way]. At this receive however, I get one character and the client crashes [Note: It crashes because it is looking for a substr in a one character string, so this isn't the real problem].

Additional Information:

I know that the server is sending information because wireshark captures the packet with a byte size of 502 [PSH, ACK], the same size for all data packets and the client replies with a [ACK] packet, so hypothetically, it gets the packet. Also, I ran into this problem before and it seemed that placing a usleep(10) between sends worked, but it does not work on this occasion.
The receive and send buffers are cleared with:

memset(miscvar, 0x0, LINE_ARRAY_SIZE)

This has always worked, but so have my recv() functions. The code for this send() - recv() is nearly identical to all the others with small variable value changes.

On another note: the recv() recieves more data that is sent, but is cut off at the null character, hence my use of memset.

My thoughts:

I feel as if C++ is racing the stack and recv() before all the data can be sent. I know this isn't true as recv() blocks. I also thought that I wasn't clearing the buffers, but atlas, I am.
--------------------------------------------------------------------------------------------------------------------

Sorry for the anecdote, but I wanted to be as specific as I can under my conditions. If you need to see some part of the code, let me know and I see if I can release it. I apologize ahead of time for any ambiguity.

[ipndrmath]

Hmm... Guess I get nothing. :)

[Laharl]

Six hours for a fairly complicated question? Give people some time, man. Especially when most of that time covers work hours in the US, where many of the experts are based.

[gpraghuram]

Why cant you use select function call to check whether data is available in the port and then start reading it.
Also can you put the recv in a loop and read till you get the whole length..

Raghu

[ipndrmath]

@ Laharl

You are absolutely right. I was eager and in all honesty, I thought I would get at least some reply even if it was just "Here's an Idea". I'm use to forums where many people post answers that rarely equate to any solution, mostly because they didn't read the post. At any rate, I apologize.

@ gpraghuram

Both valid Ideas. I'll look into select() as I have only briefly examined them. I originally thought that they only operated on Unix Domain Sockets.

How do you suppose I loop the recv() function? I can't check the exit status of the recv(), as it completes properly. I guess I could loop until I get the size, but the size is "occasionally"* dynamic.

* Sorry, this does slightly negate my original post. I was speaking generally.


Thank you for your input.

[ipndrmath]

Sorry, but this seems worthy of another post:

5. The functions read(), recv(), write(), and send() do not neces-
sarily read/write the full amount of data that you have
requested. If they do read/write the full amount, its because
you have a low traffic load and a fast stream. This is not
always going to be the case. You should cope with the case of
your functions only managing to send or receive a single byte.

6. Never read/write only in single bytes at a time unless your are
really sure that you have a small amount of data to process. It
is extremely inefficient not to read/write as much data as you
can buffer each time. The buffers in the example above are 1024
bytes although they could easily be made larger.
http://www.tin.org/bin/man.cgi?secti...pic=select_tut

Could this perhaps be my problem? I am a little confused by the above statments, they appear to contridict each other, do they not? The send()s and recv()s in both my client and server do not loop, they just sent they message in one shot. This could cause problems when the client and servers are not both on local host because of latency, but could this be the problem now? How would I properly implement this loop?

It seems as if the select() or pselect() will not work, because the recv() functions are returning true ( not less than zero) and it seems that select opperates similarly. Is this true?

[gpraghuram]

Select basically says whether data is there in the port for reading or writing.
So you should read the data in a loop and keeping track of the number of bytes read.

Raghu

[ipndrmath]

Select basically says whether data is there in the port for reading or writing.
So you should read the data in a loop and keeping track of the number of bytes read.

Raghu

Okay, I try it when I get the chance. We currently merging code so this has been set on the backburner. I will keep you updated.