Winsock recv();

[terryeverlast]

Im making a little rat program for myself. I can not get the server to accept commands.(recv function).

I know the client works.
Here is my code for the server part

if(strstr(buf,"mib"))
	 { 
  recv(current_client,title,sizeof(title),0);
  cout << title;
 
   
	 }		

Client sends MIB command. server gets MIB command. but will not receive the next command sent from client


any help..?

[terryeverlast]

bump..?

[Zhuge]

I don't think this is enough code to help you. I only see one recv(), so how is it 'getting' the "mib" command? And are you meaning the recv() on line 3 is failing (or appearing to), then?

[kbw]

... and what does the server code look like? Is it really sending stuff when you think it should be?

[terryeverlast]

solved

[kbw]

	res = recv(current_client,buf,sizeof(buf),0);	// recv cmds
	Sleep(10);
	if(res == 0)
	{
		MessageBox(0,"error","error",MB_OK);
		closesocket(current_client);
		ExitThread(0);
	}
	if (strstr(buf,"mib"))
	{
		recv(current_client,title,sizeof(title),0);

The data that you're waiting for in the second recv() could have turned up in the first recv() and may be already be in buf. In fact, that's likely unless sizeof(buf) is the exact length of fixed length commands (which I don't think is the case).

Also, recv() can fail and return -1.

And finally, why wait for 10ms before handling the error case?

[terryeverlast]

I found out my problem. The sizeof command does not work. If I manually put in howmuch byes the string is, the program works.


is there something else I can use instead of SIZEOF?

recv(current_client,buf,sizeof(buf),0);

[kbw]

sizeof does work. But remember, when you pass arrays around, the address of the first element is passed, so sizeof returns the size of the pointer.

When you pass arrays around, you have to pass the size too.

[Thumper]

sizeof does work, you're just not using it correctly. When you say sizeof(buf) you get either 4 (you're using a char pointer), or you get the entire size of the array 'buf'. You declared buf to be size 100, so sizeof(buf) = 100. So you're going to receive up to 100 bytes with that call of recv. As kbw mentioned, you're likely receiving title information in buf on your first call to recv.

Picture this scenario:

Client send: "mib SomeTitle"
Server recv 100 bytes in buf: "mib SomeTitle" <-- because you used sizeof(buf)

Server: finds "mib" in array 'buf'
Server: tries to recv title; no information in queue to recv. 

When you tell a socket to recv 100 bytes, it's going to read everything in the queue up to 100 bytes. It can fall shorter, but not larger than that amount.

You need to either A: make all of your commands a uniform length, or B: loop and receive one byte at a time and break when you receive a white space. (not sure how efficient that will be,) or C: (my favorite) just search for the title in buf, and don't worry about calling recv again.

[terryeverlast]

I got this almost working. What kbw said....I put the arrays in the scope where the sizeof is...

almost works

getting butch of weird characters

[Thumper]

If you're trying to output the full length of the array, you're going to get weird characters because there are empty space-holders for characters you didn't receive, so they just take on whatever value was already in that memory space. Try using the function ZeroMemory(Destination, length) on the buffers to write zeroes to all the memory it holds before you receive anything into them. That should eliminate your weird character problem. http://msdn.microsoft.com/en-us/library/windows/desktop/aa366920(v=vs.85).aspx

[kbw]

Remember that recv() returns the number of bytes received.

Don't access the buffer beyond that value.

[Thumper]

@kbw
That's a very good point that I had forgot about.

[terryeverlast]

SOLVED

[kbw]

You're not checking your return codes from send() and recv().

You should realise that the number of send() calls does not match the number of recv() calls. What matters is the amount of data transfered.

It is entirely possible for all those small sends to be read by a single recv() call, so both sides have to agree on what is sent, how much is sent and when it's sent (that's call a protocol). The number of send/recv calls doesn't really matter.

[terryeverlast]

thx thumper

sovled the problem iwth zero memory fuction