WinSock Tips

1.싱크로 나 이 즈 드 SOCKET 을 사용 하면 select 모델 을 사용 하고 시간 초과 가 있 는 것 이 좋 습 니 다.
2.Assuming 0 is an invalid socket handle value. Uncontrollably lame.
3
the proper closure of a connected stream socket involves:
call shutdown() with the how equal to 1
loop on recv() until it returns 0 or fails with any error
call closesocket()
Call WSACleanup()
4.stren()을 사용 하여 host ip 의 길 이 를 가 져 오지 마 십시오.
5
Assuming that a UDP datagram of any length may be sent. Criminally lame.
Reason: Various networks all have their limitations on maximum transmission unit (MTU). As a result, fragmentation will 
occur, and this increases the likelihood of a corrupted datagram (more pieces to lose or corrupt). Also, the TCP/IP service 
providers at the receiving end may not be capable of re-assembling a large, fragmented datagram.
Alternative: Check for the maximum datagram size with the SO_MAX_MSG_SIZE socket option, and don’t send anything larger. 
Better yet, be even more conservative. A max of 8K is a good rule-of-thumb.
너무 긴 데 이 터 를 보 내지 마 세 요.그렇지 않 으 면 MTU 블록 으로 인해 8K 가 딱 좋 습 니 다.
6.
Expecting errors when UDP datagrams are dropped by the sender, receiver, or any router along the way. Seeping lameness from 
every crack and crevice.
Reason: UDP is unreliable. TCP/IP stacks don’t have to tell you when they throw your datagrams away (a sender or receiver 
may do this when they don’t have buffer space available, and a receiver will do it if they cannot reassemble a large 
fragmented datagram.
Alternative: Expect to lose datagrams, and deal. Implement reliability in your application protocol, if you need it (or use 
TCP, if your application allows it).
**************************************
모델 선택
1.되도록 select()사용 을 피한다
2.소량의 연결 은 WSAAsyncSelect 또는 WSAEventSelect
3.대량 연결 용 Overlapped IO/Completion Port
Silly Window Syndrome:
송신 단 send 가 너무 빨 라 서 상대방 이 받 아들 이 는 것 이 너무 느 려 서 수신 자 에 게'슬라이딩 창 이 사용 가능 할 때'가 있 습 니 다.송신 자 는 즉시 N 바이트 의 데 이 터 를 보 냅 니 다.
이 는 오 버 헤드 를 매우 크게 만 들 고 대응 전략 은 delayed ACK 를 사용 합 니 다.
Winsock is not required to give you all the data it has queued on a socket even if your recv() call gave Winsock enough 
buffer space. It may require several calls to get all the data queued on a socket.
실시 간성 을 고려 해 야 하지 않 는 한 Nagle 알고리즘 을 닫 지 마 십시오.
TCP 바이트 흐름 에 대해 서 는 2 가지 처리 방법 을 사용 할 수 있 습 니 다.
1.데 이 터 를 보 내기 전에 2 개 이상 의 바이트 의'길이'를 추가 합 니 다.
유효한 TCP 사용:
데이터 구 조 를 잘 처리 해 야 합 니 다(메모리 정렬 문제)
WSAData 는 초기 화 할 필요 가 없습니다.WSASTARTup()은 이 구 조 를 채 웁 니 다.
2.데이터 뒤에"표시 끊 기"를 추가 합 니 다.예 를 들 어 HTTP\r
WINSOCK 로 작 성 된 프로그램 은 UNIX 시스템 과 통신 할 수 있 습 니 다.
 Is it possible to close the connection “abnormally”?
The simplest way is to call shutdown() with the how parameter set to SD_BOTH (“both directions”), optionally followed by a 
closesocket() call. Another method is to set the SO_LINGER flag to 0 with the setsockopt() call before you call closesocket
(). This causes a TCP connection reset. (That is, a TCP packet goes out with the RST flag set, forcing the remote stack to 
drop the connection immediately.)
What is UDP good for?
From the above discussion, UDP looks pretty useless, right? Well, it does have a few advantages over reliable protocols like TCP:
UDP is a slimmer protocol: its protocol header is fixed at 8 bytes, whereas TCP’s is 20 bytes at minimum and can be more.
UDP has no congestion control and no data coalescing. This eliminates the delays caused by the delayed ACK and Nagle algorithms. (This is also a disadvantage in many situations, of course.)
There is less code in the UDP section of the stack than the TCP section. This means that there is less latency between a packet arriving at the network card and being delivered to the application.
Only UDP packets can be broadcast or multicast.
This makes UDP good for applications where timeliness and control is more important than reliability. Also, some applications are inherently tolerant of UDP problems. You have likely experienced blips, skips and stutters in streaming media programs: these are due to lost, corrupted or duplicated UDP frames.
Be careful not to let UDP’s advantages blind you to its bad points: too many application writers have started with UDP, and then later been forced to add reliability features. When considering UDP, ask yourself whether it would be better to use TCP from the start than to try to reinvent it. Note that you can’t completely reinvent TCP from the Winsock layer. There are some features of TCP like path MTU discovery that require low-level access to the OS’s networking layers. Other features of TCP are possible to duplicate over UDP, but difficult to get right. Keep in mind, TCP/IP was created in 1981, and the particular implementation you are using probably has code in it going back nearly that far. A whole lot of effort has gone into tuning this protocol suite for reliability and performance. You will be throwing away those decades of experience in trying to reinvent TCP or invent something better.
If you need a balance between UDP and TCP, you might investigate RTP (RFC 1889) and SCTP (RFC 2960). RTP is a higher level prototocol that usually runs over UDP and adds packet sequence numbers, as well as other features. SCTP runs directly on top of IP like TCP and UDP; it is a reliable protocol like TCP, but is datagram oriented like UDP.
5.여러 스 레 드 에서 같은 socket 에 send 를 호출 하지 마 십시오.
Instead of multiple threads accessing a single socket, you may want to consider setting up a pair of network I/O queues. Then, give one thread sole ownership of the socket: this thread sends data from one I/O queue and enqueues received data on the other. Then other threads can access the queues (with suitable synchronization).
Applications that use some kind of non-synchronous socket typically have some I/O queue already. Of particular interest in this case is overlapped I/O or I/O completion ports, because these I/O strategies are also thread-friendly. You can tell Winsock about several OVERLAPPED blocks, and Winsock will finish sending one before it moves on to the next. This means you can keep a chain of these OVERLAPPED blocks, each perhaps added to the chain by a different thread. Each thread can also call  WSASend()  on the block they added, making your main loop simpler.
6.If two threads in an application call  recv()  on a socket,will they each get the same data?
No. Winsock does not duplicate data among threads.
Is there any way for two threads to be notified when something happens on a socket?
No.
If two threads call  WSAAsyncSelect()  on a single socket, only the thread that made the last call to  WSAAsyncSelect()  will receive further notification messages.
If two threads call  WSAEventSelect()  on a socket, only the event object used in the last call will be signaled when an event occurs on that socket.
You can’t trick Winsock by calling  WSAAsyncSelect()  on a socket in one thread and  WSAEventSelect()  on that same socket in another thread. These calls are mutually exclusive for any single socket.
You also cannot reliably call  select()  on a single socket from two threads and get the same notifications in each, because one thread could clear or cause an event, which would change the events that the other thread sees.
As recommended above, you should give sole ownership of a socket to a single thread, then have it communicate with the other threads.