im writing multithread program.
Can i call wsastartup only in main thread? Or its a mistake?

No more giving back...

Don't ask everyone, try it out and see what happens. But, if your computer blows up then I didn't suggested it, okay.

You think i know everything? On my system it works, but how long? Will it crash?

Alright, now shift your wsastartup into just the process initialisation code and try it. If it still works as expected then I would guess that you don't need to put wsastartup in each thread. Once again, if your computer blows up because of this then I didn't suggest it, okay.

Documentation says that WSACleanup terminates winsockets for all threads. It also says that WSACleanup and WSAStartup calls should be paired ("there must be a call to WSACleanup for every successful call to WSAStartup").

From these facts, you can deduce that WSAStartup can be called only in the main thread (again, if it doesn't works, then I didn't suggest it .

i used sockets in thread and everything works like a charm

pseudo-code:

however, the documentation says that you can call WSAStartup a lot of times. but it is necessary to call at least one time, then the WinSock dll intializes some necessary internal datastructures for the actual process.
if you call WSACleanup these internal structures are released.

so the original purpose is to call WSAStartup at the beginning of your main process and WSACleanup if you end using sockets.

i think its not a good idea to call WASStartup and WSACleanup inside a thread. could be a wasting ressources and maybe its not stable at all.

I can't see why you would call winsock startup/cleanup for each thread... keep yourself to a single pair, in your main thread...

And try to use as few threads as possible. Check out EventSelect.

No more giving back...

Blocking sockets = performance bottleneck.

Sure thing, non-blocking is a bit harder to program, but it's the way to go if you want to handle multiple connections (or even get decent speed with a single), unless you want to do kiddie programming.

what's wrong with (blocking ) accept() method?

Blocking isn't necessarily so bad for accept() if you expect your connect rate to be low, but once you have connections going, you do NOT want to be blocking... and you especially don't want to use protocols that impose an additional ACK layer on top of TCP, and you don't want to try and force a "packet" scheme upon TCP either.

At least not if you're going to deal with a lot of connections (p2p) or high-speed transferring (it takes some effort to saturate a gigabit LAN).

Of course if all you're trying to do is a simple IM client or echo service, who gives a fuck

No more giving back...

Kohlrak, do you have any clue how TCP works?

No more giving back...

Okay, well...

if you use UDP, you send fixed-sized packets/datagrams, which might (and likely will) appear in any order. UDP should only be used when you need really low-latency communication, and you should think long and hard before using it, for plenty of reasons; one of them being that often you end up basically re-implementing TCP on top of UDP, another being that many routers don't do proper connection tracking for UDP unless it's a protocol they know, meaning people will manually have to open ports etc... bother.

With TCP, you have a STREAM of data, and you are guaranteed the individual bytes arrive in the order they were sent. You don't have any guarantees that send(buffer, 1024) won't arrive as, say, 2x512 bytes, and small buffer sends will usually be cached for a while, since it's wasteful sending off an entire ethernet/whatever packet with small payload (google the Nagle algorithm).

Even with blocking sockets, you must always be prepared to handle whatever amount of bytes is returned to you, very likely buffering, stitching together, and splitting up as you go. So you might as well go the full mile and support async I/O, since it gives you better performance in the end.

No more giving back...

Obviously the game server utilizing would be using async I/O to avoid having a single bad client locking up the entire show :]

And fixed sizes, while it might seem convenient, isn't necessarily a good thing for performance. Just look how miserable windows filesharing (SMB/CIFS) performs on a gigabit LAN. Hint: instead of streaming files, they use fixed-size packets.

No more giving back...