Sockets: Client Sending Faster Than Host Can Receive

Aloha...

On One side of the connection i am trying to receive a buffer of size 200 three times, and on the other side i am sending 3 times (a string between 4 and 6 bytes)

but when i run this the receiver gets all 3 calls to send in the big buffer...

Then i did try to run this in debug-mode to comprehend what is happening:
the funny thing is, that now everything is working fine... somehow... i dont get this O_o...

here is the responsible code:

Sender:(a client made for testing issues)
1
2
3
4
5
6
7
8
9
10
11
12
	rc = recv(ConnectionSocket,buf,256,0);
	buf[rc] = '\0';
	rc = send(ConnectionSocket,"LOGIN",5,0);
	cout <<  rc << endl;

	char destbuf[12];
	_itoa_s(1,destbuf,10);

	rc = send(ConnectionSocket,destbuf,strlen(destbuf),0);

	rc = send(ConnectionSocket,"PWIN",3,0);
	cout << rc << endl;


and the Receiver:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
char RecvBuf[200];
	int rc;

	rc = send(sock,"WHAT?",5,0);
	if(rc < 1)
	{
		closesocket(sock);
		sock = INVALID_SOCKET;
		return;
	}

	rc = recv(sock,RecvBuf,200,0);
	if(rc < 1)
	{
		return;
	}

	RecvBuf[rc] = '\0';[...] <- followed by the two other calls to recv in another ,ethod/function
Last edited on
You are probably using a stream oriented socket such as TCP. It sounds like what you are
expecting is a datagram oriented socket (such as UDP).
hmm?... may you explain this to me, please?...

maybe what you are trying to tell me is the point, that when i call recv(sock,buf,200,0);
that it will stay receiveing untill the 200 bytes are received?...

but why does it 'work' while stepping through this?...
Show us how both sockets are initialized.
what do you mean with initialize?...

i create them...
-blocking
-IPPROTO_TCP
-SOCK_STREAM


-i normally bind , listen connect etc... just the standard stuff

i think i should loop through the send and receive buffer and clear them.
then i copy the string into it and send the whole 200 bytes to fill 'RecvBuf'

or maybe i could send the data with less bytes and send oob-data to inidicate that the main buffer does not need to be filled any more?...

or doesn´t it work, since the socket is in blocking mode...
You arent properly initing buffer. Clear it before every use or append an null char at the position returned by recv. This also explains the debug mode because your compiler probaby inits the buffer for you.
while looking at the code up there i suggest u looking at line 2 for the sender and line 18 for the receiver:P...

ofc i add the '\0'-char^^...

but even that i didnt clear the buffer after every run it is very confusing to me.

it should fill the buffer from the start when i call the routine and overwrite what was in there before




By The Way:

Thank You To All Of You For Your Help:)...
Last edited on
'\0' would do it you would be working with c string functions. You are not. The recv does not put a '\0' at the end of the buffer. Hope you solved the problem
did u read my post above?^^... as u can see in the code i add the NULL-char at the end of the buf by using

1
2
rc = recv(sock,buf,number,flag);
          buf[rc] = '\0';
I didnt check it:) So, is it working now?
rofl^^...

no it does not...
Hey Programmers,

I am still experiencing the problem as follows:

i tried to fix the Original Problem by sending 200 bytes (since the recv waits for 200 bytes)...

Now - if i dont send the ending '\0' char on my strings i cant figure out the length of the buffer i did send on my receiving method...

But -as above- when i am trying to send 5 bytes (e.g.) on someone who waits for 200 bytes (but does not need them all [a password with variable length, for example]), the receiver still waits for the last 195 bytes to fill until it returns :(...

Any help would be muchappreciated :)...
Last edited on
You can't just send on one side and receive on the other without agreeing how much to send/receive. The number of times you call send doesn't not correlate to how many times you have to call receive.
looks like i solve this by filling the rest of the buffer with some special chars at the senders side^^..


thanks to all of you :)...
Topic archived. No new replies allowed.