@25, the reason I lash out at those who cut me down when I am wrong is not the fact that its criticism. Its not that I'm offended by it. Its the manner its delivered that I have a problem with. I don't try to deliberately fail each and every time. But here's the thing. If I act arrogant, which really is impossible to tell since this is text, and not something like a voice chat where you can here my emotion and tone, and then you cut me down and quite literally force your way down my throat, your being hypocritical by first telling me not to do x and then doing it right back at me. That's not setting examples or helping anything, that's worsening it. And that's usually the trigger of all this bullshit, because both try explaining something to the other, but both sides do it in most likely the completely wrong way, and it goes on and on like this, until someone forceably breaks the argument up. When I post, I'm obviously trying to help. Telling me what I'm doing wrong in my methods of helping, or telling me what I'm doing wrong in code samples (like the one I did in post 4, which was handwritten, by the way), is fine. Doing it in such a way as to imply that you're better than me and always will be is what sets me off. That is exactly the wrong attitude. No matter how much you dislike me, I at least expect common decency. I may not have contributed anything of my own work to this community yet, but that does not mean that I haven't coded. But I'm not going to reitterate this any more. All I'm trying to say is that yes, I expect critism. Everyone does, everyone should. Its life. But if someone is forcing the way they think someone should do something down that someone's throat, and then you go and do it to them, its not going to resolve the situation, as many a topic has proven.
Now, I shall reference my remarks in post 4 where I said a vulnerability is there if you allocate ridiculously large sizes to your arrays and then feed bytes into them. To rehash, I said: "You should never accept packets in 20000-byte chunks. That leaves so many vulnerabilities open to your system its absolutely unimaginable." While this statement may have been pushed a bit far, of which I apologize for, it was most likely correct. While a denial of service attack may be the only thing we currently may be able to think of, or to find, there are most likely many others attackers either haven't found, but we don't know about them, or we just don't know they exist at all, but they're there. In the sample application kianoosh listed, the risk was literally nil; he scans the data for a specific keyword and ignores the rest. However, I was generalizing a bit; while I wrote that, I was considering the possibility that, if he allocated 20000-byte chunks in this app, he may allocate the same, if not larger, in future apps, and wanted to prevent that, since I cannot possibly predict how he'll use that data. Off the top of my head I can think of regular expression parsers, HTTP, JSON, RPC and others (though why you'd want a remote regexp parser I have no idea, unless your doing something like lambdamoo, where regexps are builtin functions).
Now, for statement two, I complained about the imports. This was primarily from a refactorization point-of-view; I myself tend to remove unused imports, and languages like Go enforce import usage. However, my first part, about error handling, was correct, as the sample has absolutely none of which I could find.
As for my third statement, I spoke about threads and mutex. I apologize for incorrect mutex/thread locking usage; I'm kinda bad at it. Again, though, I was generalizing. Sorressean, however, has already informed the OP that this was unnecessary, and I shall not reiterate it.
As for my recommendations, statement one was derived from my first 'issue'. Like that one, I thought the unused imports should be removed, since they only cause code clutter.
My third statement was... not very thought out. It is, sometimes, what I do, even if it is wrong, since the applications I do this kind of thing in are usually console apps that I want the error displayed, not just a full on .NET panic, of sorts. I mentioned putting try/catch in main() because I only do that in apps that have a main() (such as if I'm beginning a new project). (I remove them later... or I'll sometimes forget about them. Depends.)
My fourth recommendation was derived from my third 'issue'. That sample, as I said above, was handwritten, and so I certainly didn't expect it to be perfect. It was only showing how to use mutexes in .NET, not as a full-on example, even if I may have portrayed it as such.
Post 6 may have been a bit harsh. However, I found post 5 a bit confusing (the statement "Never use library's for networking" made me think "What? Wow?"). Post 8 was because I read post seven, and I thought he meant communication with the networking card via something like POSIX. I, too, apologize for my rudeness in that one. Post 9 cleared up most of my confusion, though I still consider higher-level libraries much easier to use because I don't need to worry about low-level packet transmissions, though if I need to dip into the low-level system I will do so. (Boost.Asio is ridiculously hard to use, from what I've seen of it. The samples I've seen of it make me shy away from it. Maybe I'm not fully understanding it... dunno.)
I hope this explanation clears up some things. Maybe it won't, maybe it will.
"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." — Charles Babbage.