Alternatives to winsock?

[Evan M]

I'm creating a multiplayer game using winsock, but I've been having several problems with winsock. I've been searching for an alternative to it, but I haven't found anything. If anyone could point me to something I could use in place of winsock (a free something), I would greatly appreciate it.

[Salem]

> but I've been having several problems with winsock.
Such as?

If it's because your programs are crashing, or have odd behaviour?
Then I'm afraid that's all down to bugs in your code. Changing libraries won't solve anything.

Or is there some aspect of network functionality you deperately need?
In which case, you should state your requirements.

[Evan M]

> but I've been having several problems with winsock.
Such as?

The largest problem is that winsock appears to be appending data to the end of the buffer, in which case, how am I supposed to read the end of the buffer? It is also appending garbage data, which I am positive I never sent.

If it's because your programs are crashing, or have odd behaviour?

Aside from the buffer problem, there's no crashing or odd behavior.

Or is there some aspect of network functionality you deperately need?
In which case, you should state your requirements.

I just need something that will send and receive data. When I used to program Visual Basic, winsock worked perfectly, but not so with C++.

[mahlerfive]

I can guarantee you the problem is not winsock, it is something you are doing.

Can you post a little code where you are having the problem, tell us what you are trying to send and what you are receiving?

[Salem]

> The largest problem is that winsock appears to be appending data to the end of the buffer
My guess is that you're assuming recv() appends a \0 (it doesn't), and you're also not paying close enough attention to the return result of recv() either.

> When I used to program Visual Basic, winsock worked perfectly, but not so with C++.
Ah, that explains everything. The API has been mucked about with "for your convenience" rather than adhering to any standard.

[Evan M]

Here's the code I wrote for retrieving stuff in the buffer. It works at first, but later on it keeps reading the same thing over and over. From what I gathered on MSDN, recv should flush the buffer each time it is read, but it is not doing that. Also, I don't think this matters, but this is run in a seperate thread.

int dataRetrieval( void *data )
{
	while( !quit ) {
		if( mainCanReadBuffer == false ) {
			char tempBuffer[100];
			int error = recv( sock, tempBuffer, 100, 0 );
			int bytes = 0;
			while( tempBuffer[bytes] != '\0' && bytes < 100 ) {
				bytes++;				
			}
			delete [] buffer;
			buffer = new char[bytes + 1];
			for( int i = 0; i <= bytes; i++ ) {
				buffer[i] = tempBuffer[i];
			}
			mainCanReadBuffer = true;
		}
	}

	return 0;
}

I send data like this:

stringstream infoHolder;
infoHolder << "coord" << players[myRect].y << "\0";
send( sock, infoHolder.str().c_str(), sizeof( infoHolder.str().c_str() ) * infoHolder.str().length(), 0 );

[Salem]

Yeah, that's pretty much wrong. You can't look at the data to determine what happened.

char tempBuffer[100];
int error = recv( sock, tempBuffer, sizeof(tempBuffer)-1, 0 );
if ( error > 0 ) {
  // error is the number of bytes received.
  tempBuffer[error] = '\0';  // we allowed room for this with the -1 in the recv
} else if ( error == 0 ) {
  // connection closed
} else {
  // an error
}

OK, the next problem you have to solve (assuming this is a TCP connection) is fragmentation.
Say for example, you send (in one call)
"hello world".
Now it's entirely possible that at the recv end, you'll get "hello wo" and then sometime later, "rld". It's your job to reassemble the message into it's proper form. One way would be to frame your messages with say a \n

It gets worse. Fragmentation can also happen on the send() call as well. You need to look at that return result as well to make sure that you sent everything. If not, you need to call send() again with the remainder of the buffer (until it's all gone).

[dmanw100]

I'm just dabbling in the communications section but I wondered what you meant by framing the message with "\n" to reassemble it. Do you mean sending something like an array of characters with a "\n" placed in the last entry and then piecing all incoming data together until a "\n" is reached? Any good place to learn about winsock other than MSDN?

[Salem]

> Do you mean sending something like an array of characters with a "\n" placed
> in the last entry and then piecing all incoming data together until a "\n" is reached?
That's exactly what it means.

The "standard" tutorial for network programming is "beej".

[mahlerfive]

The only problem with this method is that if you actually want to send a \n, you are out of luck. The approach I use is to tack on an integer on the front of each message to tell the receiver how many characters to expect. The receiver can then keep looping recv() until it has read that many characters. Similary, the sender can keep looping send() until it has actually sent that many characters.

[dmanw100]

Thanks for the "beej" I just started reading it!