[Solved] WinSock TCP - Crash if buffer over around 5000

Networking and Multiplayer Programming

Started by irbaboon October 09, 2011 11:05 AM

10 comments, last by irbaboon 12 years, 6 months ago

1,631

Author

October 09, 2011 11:05 AM

Hi, so I am currently making a game with WinSocket, and I want the server to send maps to the client...
However, I've got a problem...

I have a #define which is the default buffer length, if I change that to over 4997, it will make the client freeze and not respond until the server gets closed.
Both recv and send uses that buffer length.

Is there a way to make it possible to send and recv more than 4997 bytes?

I'd guess it's not the default with everyone, but it seems to be for me... Any help is greatly appreciated

Geri

407

October 09, 2011 11:22 AM

the problem is maybee in your code.
btw i always split the data packages to size 2048, and wait until all data being recived. maybee that will help on you.

irbaboon

1,631

Author

October 09, 2011 11:25 AM

Hmm, I'm really unsure how I would do that, as I can't send more than 4977 bytes per send...
Making a different code for sending and receiving each map is not too efficient...

I have no idea how the code can cause it to be honest, everything should depend on the #define ...

Thanks for your reply though

Edit:
Weird, I typed in 5499 or something and it worked, now I changed to 7200 to check if it actually works, but it crashes again...

Geri

407

October 09, 2011 11:34 AM

like... let=2048;while(1) ... send( &total[step]..., let) ... step+=2048; while(step+let>=total) lett--;

irbaboon

1,631

Author

October 09, 2011 11:37 AM

I will do something like that if there is no other choice, but for now I want to try to see if I can get rid of this limit... As it shouldn't be limited.

Edit:
It's weird how it seems the max is increasing... I can now send and recv around 5720...

Any ideas?

Edit 2:
Ehm, I'm using TCP by the way... I don't think I should manually split the packets ...

rip-off

11,000

October 09, 2011 01:11 PM

Show us your code - try build a minimal program that demonstrates the behaviour.

blog | twitter

irbaboon

1,631

Author

October 09, 2011 01:33 PM

Ooh, I'm so glad that you didn't mention any limit

Here are the send and recv usage, I think this should be enough?
If not, then please ask.

#define BUFFERSIZE 9000



bool SendData(SOCKET _sdsock, string _sddata, bool _sdlog)

{

	const char *_sdtemp = Char(_sddata);

	if (send(_sdsock, _sdtemp, BUFFERSIZE, 0) == SOCKET_ERROR) {

    	if (_sdlog) {

        	cout << "\nError while trying to send data: " << _sdtemp << endl;

        	cout << "Error: " << WSAGetLastError() << endl;

    	}

    	return false;

	} else {

    	if (_sdlog) {

        	cout << "\nSuccessfully sent data: " << _sdtemp << endl;

    	}

    	return true;

	}

}



bool RecvData(SOCKET _rdsock, string &_rddata, bool _rdlog)

{

	char _rdtemp[BUFFERSIZE + 1];

	if (recv(_rdsock, _rdtemp, BUFFERSIZE, 0) <= 0) {

    	if (_rdlog) {

        	cout << "\nError while trying to receive data: " << _rdtemp << endl;

        	cout << "Error: " << WSAGetLastError() << endl;

    	}

    	_rdtemp[0] = 0;

    	return false;

	} else {

    	if (_rdlog) {

        	cout << "\nSuccessfully received data: " << _rdtemp << endl;

    	}

    	_rddata = _rdtemp;

    	_rdtemp[0] = 0;

    	return true;

	}

}

patrrr

1,323

October 09, 2011 03:23 PM

You're outputting a possibly non-terminated string; recv doesn't add any 0s to the data. If the data is split up, you'll get a fragment of the original string without a trailing 0. std::string has a constructor where you can pass a const char * and the length:



ssize_t rxSize = recv(_rdsock, _rdtemp, BUFFERSIZE, 0)

...

_rddata = std::string(_rdtemp, rxSize);



// or you can use the assign function:

_rddata.assign(_rdtemp, rxSize);

Why are you doing _rdtemp[0] = 0 before returning? It goes out of scope anyway.

[font="arial, verdana, tahoma, sans-serif"]

I will do something like that if there is no other choice, but for now I want to try to see if I can get rid of this limit... As it shouldn't be limited.

Edit:
It's weird how it seems the max is increasing... I can now send and recv around 5720...

Any ideas?

Edit 2:
Ehm, I'm using TCP by the way... I don't think I should manually split the packets ...

[/font][font="arial, verdana, tahoma, sans-serif"]The data can be split up, and multiple sends can be concatenated together. If you send 100 bytes, you're not guaranteed to get 100 bytes from one call to recv. BTW; there are no "packets" in this layer.

[/font]

irbaboon

1,631

Author

October 10, 2011 03:35 AM

Thanks for your reply, but I managed to fix this. It was the SendData function that was failing. I sent the size of BUFFERSIZE... I thought that was okay, but it seems it's not.

patrrr

1,323

October 10, 2011 08:44 AM

If the 'Char' function (is it a function or a type...?) gives less data than BUFFERSIZE, then that's a problem of course; send would read too much from memory. I strongly suggest you to consider all the input in this thread, and learn why the input is sensible. This is a sensitive part of the code, and strange bugs can/will occur in the future if you don't get it right.

[Solved] WinSock TCP - Crash if buffer over around 5000

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

[Solved] WinSock TCP - Crash if buffer over around 5000

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines