1、通信长度，这个是你自己决定的，没有系统强迫你要发多大的包，实际应该根据需求和网络状况来决定。对于TCP，这个长度可以大点，但要知 道，Socket内部默认的收发缓冲区大小大概是8K，你可以用SetSockOpt来改变。但对于UDP，就不要太大，一般在1024至10K。注意一 点，你无论发多大的包，IP层和链路层都会把你的包进行分片发送，一般局域网就是1500左右，广域网就只有几十字节。分片后的包将经过不同的路由到达接 收方，对于UDP而言，要是其中一个分片丢失，那么接收方的IP层将把整个发送包丢弃，这就形成丢包。显然，要是一个UDP发包佷大，它被分片后，链路层 丢失分片的几率就佷大，你这个UDP包，就佷容易丢失，但是太小又影响效率。最好可以配置这个值，以根据不同的环境来调整到最佳状态。
send()函数返回了实际发送的长度，在网络不断的情况下，它绝不会返回(发送失败的)错误，最多就是返回0。对于TCP你可以字节写一个循环发送。当 send函数返回SOCKET_ERROR时，才标志着有错误。但对于UDP，你不要写循环发送，否则将给你的接收带来极大的麻烦。所以UDP需要用 SetSockOpt来改变Socket内部Buffer的大小，以能容纳你的发包。明确一点，TCP作为流，发包是不会整包到达的，而是源源不断的到， 那接收方就必须组包。而UDP作为消息或数据报，它一定是整包到达接收方。
2、关于接收，一般的发包都有包边界，首要的就是你这个包的长度要让接收方知道，于是就有个包头信息，对于TCP，接收方先收这个包头信息，然后再收包数 据。一次收齐整个包也可以，可要对结果是否收齐进行验证。这也就完成了组包过程。UDP，那你只能整包接收了。要是你提供的接收Buffer过小，TCP 将返回实际接收的长度，余下的还可以收，而UDP不同的是，余下的数据被丢弃并返回WSAEMSGSIZE错误。注意TCP，要是你提供的Buffer佷 大，那么可能收到的就是多个发包，你必须分离它们，还有就是当Buffer太小，而一次收不完Socket内部的数据，那么Socket接收事件 (OnReceive)，可能不会再触发，使用事件方式进行接收时，密切注意这点。这些特性就是体现了流和数据包的区别。
补充一点，接收BuffSize >= 发送BuffSize >= 实际发送Size，对于内外部的Buffer都适用，上面讲的主要是Socket内部的Buffer大小关系。
阻塞模式下 Server 端与 Client 端之间的通信处于同步状态下。在 Server 端直接实例化 CSocket 类，调用
Create 方法创建 socket ，然后调用方法 Listen 开始侦听，最后用一个 while 循环阻塞调用 Accept
函数用于等待来自 Client 端的连接，如果这个 socket
在主线程（主程序）中运行，这将导致主线程的阻塞。因此，需要创建一个新的线程以运行 socket 服务。
调试跟踪至 CSocket::Accept 函数源码：
while(!Accept(...))
{
// The socket is marked as nonblocking and no connections are
present to be accepted.
if (GetLastError() == WSAEWOULDBLOCK) PumpMessage(FD_ACCEPT);
else
return FALSE;
}
它不断调用 CAsyncSocket::Accept （ CSocket 派生自 CAsyncSocket 类）判断
Server 端 socket 的事件队列中是否存在正在引入的连接事件 - FD_ACCEPT （见 1 ），换句话说，就是判断是否有来自
Client 端 socket 的连接请求。
如果当前 Server 端 socket 的事件队列中存在正在引入的连接事件， Accept 返回一个非 0 值。否则， Accept 返回
0，此时调用 GetLastError 将返回错误代码 WSAEWOULDBLOCK ，表示队列中无任何连接请求。注意到在循环体内有一句代码：
PumpMessage(FD_ACCEPT);
PumpMessage 作为一个消息泵使得 socket window 中的消息能够维持在活动状态。实际跟踪进入 PumpMessage
中，发现这个消息泵与 Accept 函数的调用并不相关，它只是使很少的 socket window 消息（典型的是 WM_PAINT
窗口重绘消息）处于活动状态，而绝大部分的 socket window 消息被阻塞，被阻塞的消息中含有 WM_SOCKET_NOTIFY。
很显然，如果没有来自 Client 端 socket 的连接请求， CSocket 就会不断调用 Accept 产生循环阻塞，直到有来自
Client 端 socket 的连接请求而解除阻塞。
阻塞解除后，表示 Server 端 socket 和 Client 端 socket 已成功连接， Server 端与 Client
端彼此相互调用 Send 和 Receive 方法开始通信。
非阻塞模式
在非阻塞模式下 利用 socket 事件 的消息机制， Server 端与 Client 端之间的通信处于异步状态下。
通常需要从 CSocket 类派生一个新类，派生新类的目的是重载 socket 事件 的消息函数，然后在 socket 事件
的消息函数中添入合适的代码以完成 Client 端与 Server 端之间的通信，与阻塞模式相比，非阻塞模式无需创建一个新线程。
这里将讨论当 Server 端 socket 事件 － FD_ACCEPT 被触发后，该事件的处理函数 OnAccept
是如何进一步被触发的。其它事件的处理函数如 OnConnect, OnReceive 等的触发方式与此类似。
在 上面 中已提到 Client/Server 端通信时， Server 端 socket 正在接收来自 Client 端 socket
连接请求，这将会触发 FD_ACCEPT 事件，同时 Server 端的 网络传输服务进程 向 Server 端的 socket window
(CSocketWnd ）发送事件通知消息 WM_SOCKET_NOTIFY , 通知有 FD_ACCEPT 事件产生 , CsocketWnd
在收到事件通知消息后，调用消息处理函数 OnSocketNotify:
LRESULT CSocketWnd::OnSocketNotify(WPARAM wParam, LPARAM lParam)
{
CSocket::AuxQueueAdd(WM_SOCKET_NOTIFY, wParam, lParam);
CSocket::ProcessAuxQueue();
return 0L ;
}
消息参数 wParam 是 socket 的句柄， lParam 是 socket 事件
。这里稍作解释一下，CSocketWnd 类是作为 CSocket 类的 友元类 ，这意味着它可以访问 CSocket
类中的保护和私有成员函数和变量， AuxQueueAdd 和 ProcessAuxQueue 是 CSocket
类的静态成员函数，如果你对友元不熟悉，请迅速找本有关 C++ 书看一下友元的使用方法吧！
ProcessAuxQueue 是实质处理 socket 事件的函数，在该函数中有这样一句代码： CAsyncSocket* pSocket
= CAsyncSocket::LookupHandle((SOCKET)wParam, TRUE);
其实也就是由 socket 句柄得到发送事件通知消息的 socket 指针 pSocket：从 m_pmapSocketHandle
中查找！
最后， WSAGETSELECTEVENT(lParam) 会取出事件类型，在一个简单的 switch
语句中判断事件类型并调用事件处理函数。在这里，事件类型是 FD_ACCEPT ，当然就调用 pSocket->OnAccept ！
Server 端 socket 处于阻塞调用模式下，它必须在一个新创建的线程中工作，防止主线程被阻塞。
当有多个 Client 端 socket 与 Server 端 socket 连接及通信时， Server
端采用阻塞模式就显得不适合了，应该采用非阻塞模式 , 利用 socket 事件 的消息机制来接受多个 Client 端 socket
的连接请求并进行通信。
在非阻塞模式下，利用 CSocketWnd 作为所有 sockets 的消息池，是实现 socket 事件
的消息机制的关键技术。文中存在用词不妥和可能存在的技术问题，请大家原谅，也请批评指正，谢谢！
当前模块状态——用于保存当前线程和模块状态的一个结构，可以通过 AfxGetThreadModule()
获得。AFX_MODULE_THREAD_STATE 在 CSocket 重新定义为 _AFX_SOCK_THREAD_STATE 。
socket 类型——在 TCP/IP 协议中， Client/Server 网络程序采用 TCP 协议：即 socket 类型为
SOCK_STREAM ，它是可靠的连接方式。在这里不采用 UDP 协议：即 socket 类型为 SOCK_DGRAM ，它是不可靠的连接方式