Multiplayer Programming

Please read the forum FAQ. It contains the exact lists you have asked for.

If you are a beginner in game programming and have a little knowledge of c# then it is better to network-program in xna.It is quite easy just like two lines of code and you have no errors.Wanna learn something DirectPlay in C#.Net is also quite easy.
Xna tutorials are available at 01FES and DirectPlay will be very soon.You check out tutorials at :

http://www.01fes.com/

At the risk of giving hplus0603 the shits . You could try the tutorials here:

Winsock tutorials

At the risk of giving hplus0603 the shits . You could try the tutorials here:

Winsock tutorials

Winsock Tutorial 1

// Display message from server
char buffer[1000];
memset(buffer,0,999);
int inDataLength=recv(Socket,buffer,1000,0);
std::cout<<buffer;

[/quote]

Yea, you better be really careful reading through those. I see a lot of problems in all examples that can lead you down the path of network programming ruin. If you wanted to follow a tutorial like that, you have to consult MSDN for every API function used to see how to correctly use it. 99% of the time, those simple tutorials misuse them and if you blidnly follow them, your programs will be incorrect. They may still work, but they will nonetheless still be incorrect.

I fail to see have this is 'wrong' any way. The tutorials show, with great explanation, what is happening. Also all having reference to MSDN at the bottom of the page.

If you want to see examples of fully fledged servers with full error checking and server/client security, you might want to ask Blizzard if they can supply you with the source code for Battle.net or something.


// Display message from server
char buffer[1000];
memset(buffer,0,999);
int inDataLength=recv(Socket,buffer,1000,0);
std::cout<<buffer;


I agree. That code is pretty terrible! It looks like a typical example of someone thinking "I'm trying to learn this network programming thing, so I'll write a tutorial about how to do it!" and then putting at least four beginner-level mistakes in it.
First, you don't need to clear the buffer before you recv() into it, because recv() will overwrite it and doesn't care what's in it.
Second, you need to make sure you manually zero terminate the string, because recv() may not actually return a zero-terminated string. As it is, a string of 999 or of 1000 bytes will not be zero terminated (because only the first 999 bytes are cleared, so the last byte is non-0, and that last byte may or may not be overwritten by the call to recv()).
Third, it needs to test inDataLength for a return value of less than 1, which generally means some error condition. ("stream closed" on 0, if it's TCP, and "error" on -1)
Fourth, if this is using TCP, which is likely because it's recv() instead of recvfrom(), then that code will totally lose all bytes after an embedded 0, which may be all or part of whatever the next message was that the other end sent.

You don't need to manually terminate with zero because memset has done this allready .

Agreed, the 999 should be 1000.


With the error checking. There is a whole tutorial on that, if you read deep enough. It even states on the the following;

Previously we purposely omitted too much detail in error handling so as not to overwhelm newcomers. Now we examine error handling in greater detail. When we are finished, we should be able to troubleshoot our applications so we can pinpoint where a problem may exist with greater efficiency.[/quote]

So, the mistakes in the code total 1 (not 4). And this mistake is far from critical.

Tutorials are there to give an insight on how to do something. Not a fully fledged solution. It is upto the coder what they do with the 'insight'.

How many examples on MSDN use full error checking?

They provide information how you can use a function and advise on how errors are handled. This is exactly what win32developer.com does.

So, the mistakes in the code total 1 (not 4). And this mistake is far from critical.

I see more errors than that, and many of them are critical. They are quite likely to happen, even in a short demo or tutorial.




Remember that TCP is a stream protocol. You may not retrieve the entire string (assuming you are sending a string). You also may retrieve more than a single string. You absolutely must account for this.

You have no guarantee that you will receive your entire string. You also have no guarantee that you won't receive more than your string.

1. Failure to handle a complete object is a critical failure that will leave your system in an invalid state.
2. Failure to handle more than one full object is a critical failure that will leave your system in an invalid state.
3. Failure to properly handle string termination is a critical failure that will likely crash your program.

These are very likely to happen to anybody using your tutorial, so you need to be prepared to deal with them.

4. Failure to detect a transfer error is a failure, although slightly less critical for a tutorial.
5. Misuse and misunderstanding of how memory works is a performance error. You need to set at most one byte, more likely you need to set zero bytes.
6. Improper use of magic numbers is a style error, and would have prevented one of your bugs.



Looking over those specific tutorials, they are all riddled with bugs. It certainly seems to me like it is a tutorial written by a beginner.

You don't need to manually terminate with zero because memset has done this allready .

In my opinion, when you're in a hole, you should stop digging. You just right now showed that not only do you not understand insecure code, you don't even understand a problem when pointed out to you.

If the buffer is 1000 bytes long, and I send a packet of 1000 non-zero bytes, then the buffer will not be zero terminated, no matter what you put into the buffer before it gets overwritten by the data I send to it.

Really. Network programming is super hard. The human brain isn't REALLY made to understand it at all, because it's not like any process that normally occurs "on the Savannah." I make mistakes often enough, which is why I try to get code reviews for any code I write, and I fix problems that people point out. You should not take feedback on bad code and just ignore it, or worse, disregard it.

I fail to see have this is 'wrong' any way. The tutorials show, with great explanation, what is happening.

I'm not trying to bash anyone's work. In terms of constructive criticism, there's no reason to sugar coat it nowadays. It's one of those things where, once you learn the stuff and look back at these types of tutorials, you can see how flawed they are and how they are really doing more harm than good for what they are trying to attempt. The explanations are not great or even good for that matter and there are a lot of issues all around with the tutorials. But once again, I'm not sitting here trying to bash it. You could find tons of my previous work and posts from over the years that suffers from the same exact issues. The only difference is I'm sitting here acknowledging I have made a lot of those mistakes in the past and actively work to avoid doing the same in the future.

I don't expect anything to be written perfectly. I for one cannot write prefect code so I won't hold anyone to any higher standards then I hold myself. With that said though, fundamental design flaws and general misunderstanding of the topics being presented are a real issue with those tutorials. I'm not going to go through and list them all or say they can improve by doing this and that because then it's my work and not theirs. The 999 being there rather than 1000 would be one of the typos that just happens. The concept of clearing the buffer before using it in recv the way they do however, is a misunderstanding of the way things work, as already mentioned. Using "\r\n" in C++ over std::endl in std::cout is another issue that raises eye brows in modern C++ programming.There's a very specific reason for either and it shouldn't be 'because it's less typing' (not saying that is the reason it was being used).

The real killer for me though is this:

Winsock Tutorial 8
All too easy, so far. You'll be writing the next block buster MMO before you know it! [/quote]

There are so many things wrong with that statement, regardless if it was said in humor or not, that once again the Don't write tutorials article has to be referenced. Regardless of why it was said and in what manner it was said, people trying to learn will read it and believe it. This is why so many people come to GameDev (and many other sites) trying to write MMOs with no real experience of networking or even game programming. Tutorials like this one (unintentionally) misrepresent the true nature of the concepts and then people go on under false pretenses thinking they can just jump right in and make it work.

The biggest problem with trying to teach programming concepts by writing tutorials, guides, and articles is that there is no real consequences. Pretend for a moment firearms handling was taught the same way most programming tutoirals were. Safety issues and handling were ignored at first and students were given live fire weapons fully loaded with safety off. What do you think would happen? Nothing like that exists in our digital world at this stage of 'getting started'. The places where it does exist (medical, military, for example) it's far too late as such tragic events happen due to some misunderstood programming concept or implementation of which the programmer would not suffer consequences until after something happened (granted they were proven liable).

As hplus said, network programming is hard; trying to teach it is even harder. After a while working with this stuff and getting a lot of experience, you come to realize that trying to teach doesn't really help in this domain. Guiding people along a specific knowledge path so they can teach themselves does. Rather than write another 20 paragraphs about this, I'll simply point out that is the approach I took in my own resource: A guide to getting started with boost::asio. There is certainly room from improvement, as with anything, but read through all of the tutorials on the Win32 site and then read through mine. You should notice a significant difference in everything presented.

Last but not least, these resources are only relevant to learning the networking API you are using. Regardless of what API you choose to use, that is only a small fraction of the networking domain you have to be aware of. Just because you know WinSock or boost or ACE, it doesn't mean you are all set to undertake any networking project. It just means you have some of the tools you need at your disposal. There are still issues of application protocol design, serialization, database interactions, synchronization, and so on that are not specific to the networking API you actually choose. Actually trying to find resources for that stuff is hard because such knowledge is usually kept under lock and key. That means for most of the good stuff, you have to work it out yourself by studying their implementations

So the main takeaway is this:
- Always start with official documentation and references
- Take any unofficial article, guide, or online resource with a grain of salt. Always double check what is being shown to official documentation to ensure you aren't learning things the wrong way.
- There is no easy/fast way around it. If you try, you will end up wasting time and having to go back and relearn things the right way once you come to realize most of everything you are doing is wrong.
- "It's not always like it is in the books." - most of the good stuff you will end up having to figure out on your own by studying existing systems in depth. Just because someone makes something work for their system, doesn't mean you can make it work for yours!
- It's not easy taking other peoples' word for this stuff. You should question everything you are told. However, you should also assume there might be more to it than you know, so there's a chance you just aren't able to understand why people say certain things you don't agree with at the time. Keep an open mind, put on your detective hat, and find out yourself, however long it takes!