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!