Some issues with sockets...

Started by
5 comments, last by ANSI2000 22 years, 2 months ago
Lets say I do a recv() with a buffer of 1k (1000 bytes) in sync mode... Will say that the sending side is only gona be sending 500 bytes of data... Because of netwrok congestions etc... Is it possible that the 500 bytes get choped in 2 or more chunks, requiring to read more then once? So I do my read and I and only get back 100 bytes, but I know that there si suposed to be 500 bytes comming through. I must read again until I get all 500 bytes or will tcp/ip ensure that the sending socket will send all 500 bytes and the receiving socket will receive all 500 bytes...
Advertisement
You''ll have to read several times until the application knows there is no more data coming.

And the reverse can happen too. If you send 2 500-byte messages, you could read, say 750 bytes the first time, which will require you to recognize the message boundary yourself.

UDP will keep the messages separated... but doesn''t guarantee they''ll reach destination.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Wrong forum - moved to Multiplayer and Network Programming.

Basically, you should never assume your data will come in one chunk. Even if it does all come in one chunk, there might be other data following it from a successive call. So you should have ways of buffering it and delimiting it at your end.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
I kinda new it... Because here at work... I do lots of network programming dealing with banks around the world... And today I was reading up on some specs for ISO 8583 and no where in the response message does it say that there should be a delimiting character or a message length... I was just wondering thats all
If you want to ''packetize'' a TCP/IP stream you''ll need some sort of message delimiter, that''s true. More info on that topic can be found here :
http://tangentsoft.net/wskfaq/examples/packetize.html

hope that helps
This is what I use of course the code can be cleaned up...

But in the world of business and dead lines, if it aint broke dont fix it

bool Socket::read(char *pData, int pBufferLength, BYTE pTerminator, int &pBytesReceived){	int errorCode;	int bytesReceived = 0;	int accumulatedBytes = 0;		bool terminate = false;	while(!terminate)	{				bytesReceived = recv(sock, (pData + accumulatedBytes), (pBufferLength - accumulatedBytes), 0);		if (bytesReceived == SOCKET_ERROR)		{			errorCode = WSAGetLastError();				if(debug)				printf("Socket::read() - Error Code: %d\n", errorCode);					return(false);		}		accumulatedBytes += bytesReceived;		if(bytesReceived == 0)			break;				// Look for the terminating character in the chunk of data received from		// the socket. Ineficient should check each chunk received instead of the		// entire buffer.		for(int i = 0; i < accumulatedBytes; i++)		{			if(pData == pTerminator)  // There is an index here not showing because of HTML tags!!!				terminate = true;		}	}		// Terminate the string.	pData[accumulatedBytes] = '\0';	pBytesReceived = accumulatedBytes;		if(debug)		printf("Socket::read() - Bytes Received: %d\n", accumulatedBytes);	return(true);}  


Edited by - ANSI2000 on February 22, 2002 10:10:36 AM
there is a problem because if the network is congested you might read less than the buffer size and in that case recv() will return SOCKET_ERROR with WSAEWOULDBLOCK I believe set as error value. In that case there is more data to be read but not yet available. Either you could block on recv() or come back at a later time to retrieve the rest of the data. In that case you would have to remember the read pointer, for instance by making it a static variable and have another static flag ''read_in_progress'' or something like that set.

This topic is closed to new replies.

Advertisement