TCP同步与异步及阻塞模式，多线程+阻塞模式，非阻塞模式简单介绍
首先我简单介绍一下同步TCP编程 与异步TCP编程。
在服务端我们通常用一个TcpListener来监听一个IP和端口。客户端来一个请求的连接，在服务端可以用同步的方式来接收，也可以用异步的方式去接收。比如：
TcpListene server = new TcpListener(IPAddress.Parse("127.0.0.1"), port);
TcpClient tc =server.AcceptTcpClient();
这里就一个同步接收的方式，那为什么说同步呢，因为在这个端口下如果同是来了两个客户端请求，第一个连接得到响应，与服务端建立通讯，而第二个请求就会被一直阻塞直到第一个请求完成操作，各个请求之间就好像排个队，顺序执行，这就是同步。
异步呢，就是同时来两个或者多个请求，服务端就同时响应多个客户端，同时给他们连接。各个客户端与服务器的通讯是并行的，一个客户端不必等另一个客户端完成操作。通常用这两个方法来接收一个客户端请求。
BeginAcceptTcpClient（）
EndAcceptTcpClient（）
//----------------------------------------------------------------------------------------------------------------------
最近练习一个程序 订票客户管理系统。用到TCP编程。
这个程序可以从用三种模式来完成。
1.阻塞模式（仅适合短连接）
这样。
TcpListene server = new TcpListener(IPAddress.Parse("127.0.0.1"), port);
while（true）
{
TcpClient tc =server.AcceptTcpClient();
// do ........................
}
来一个连接服务端端就响应了，然执行操作，如果操作没完成再来一个客户端请求就阻塞你，直到第一个请求完成操作。
总结特点：这种模式简单易行，适合客户端请求次数比较少场景。比如一下来了1000个请求，第一个去执行了 ，剩下的999个被阻塞。
2.多线程+阻塞模式（用于长连接和短连接）
TcpListene server = new TcpListener(IPAddress.Parse("127.0.0.1"), port);
while（true）
{
TcpClient tc =server.AcceptTcpClient();
//接收到客户端请求之后 就起一个线程 负责这个客户端TCP与服务端的通讯
Thread Th=new Thread(F);
Th.start();//有参数加参数没参数不加
}
void F（ object oo）
{
//和客户端进行通讯
}
想 这样，一个请求来个，服务端响应然后给你一个线程负责和你的通讯。然后服务端又去响应其他客户端的请求。而不必等待前一个连接是否完成操作。这样模式由于 引入了多线程，就变成了异步操作就要考虑对临界资源的互斥问题，就是让多个线程访问一个资源时候，去同步他们的操作。这里不再说了。
在负责给客户端的方法中 这里我随便写了个F（object oo）如果关闭当前连接。就是异步的端连接， 如果不关就是异步的长连接。根据需要来确定。
总结特点：这种模式由于引入了多线程，提高了系统的效率，但是要考虑临界资源的互斥问题，如何管理线程生命周期。
3 非阻塞模式
就不在用AcceptTcpClient()这种阻塞方式来接收请求。就是来一个请求马上接收。
通常用这两个方法组合使用
TcpListene server = new TcpListener(IPAddress.Parse("127.0.0.1"), port);
server.Start();
server.BeginAcceptTcpClient(new AsyncCallback(AcceptClient), server);
void AcceptClient(IAsyncResult ar)
{
TcpListener server = (TcpListener)ar.AsyncState;
TcpClient client = server.EndAcceptTcpClient(ar);
}
当执行BeginAcceptTcpClient时候编译器就会在线程池中创建一个线程监听连接请求，如果有请求就会自动调用委托的方法（这里的AcceptClient）来完成一个 TcpClient 的实例，再来一个客户端请求，线程池又新建一个线程去实例一个TcpClient对象，当然了如果想做长连接的多客户端与服务端的通讯时候，每一个TcpClient对象是要保存起来的，这只是异步的接收请求而已。
听说做大型项目异步接收用的很多。
|
|
| 阻塞模式
非阻塞模式
Socket的阻塞模式和非阻塞模式
来源:http://blog.csdn.net/VCSockets/
I/O多路复用（同步I/O模式） 使用select()、poll()等函数实现对多个socket的同步I/O操作。它能同时等待多个socket描述符，而这些socket描述符其中的任意一个进入读就绪/写就绪/出错状态，select()函数就可以返回。请参见函数说明和程序
信号驱动I/O
异步I/O
|
阻塞模式
Windows套接字在阻塞和非阻塞两种模式下执行I/O操作。在阻塞模式下，在I/O操作完成前，执行的操作函数一直等候而不会立即返回，该函数所在的线程会阻塞在这里。相反，在非阻塞模式下，套接字函数会立即返回，而不管I/O是否完成，该函数所在的线程会继续运行。
在阻塞模式的套接字上，调用任何一个Windows Sockets API都会耗费不确定的等待时间。图所示，在调用recv()函数时，发生在内核中等待数据和复制数据的过程。
当调用recv()函数时，系统首先查是否有准备好的数据。如果数据没有准备好，那么系统就处于等待状态。当数据准备好后，将数据从系统缓冲区复制到用户空间，然后该函数返回。在套接应用程序中，当调用recv()函数时，未必用户空间就已经存在数据，那么此时recv()函数就会处于等待状态。
Windows套接字程序使用“生产者-消费者”模式来解决上述问题。在程序中，“生产者”读入数据，“消费者”根据需求对读入数据进行处理。通常“生产者”和“消费者”存在于两个线程中，当“生产者”完成读入数据时，使用线程同步机制，例如设置一个事件通知“消费者”，“消费者”接收到这个事件后对读入的数据进行处理。
当使用socket()函数和WSASocket()函数创建套接字时，默认的套接字都是阻塞的。这意味着当调用Windows Sockets API不能立即完成时，线程处于等待状态，直到操作完成。
并不是所有Windows Sockets API以阻塞套接字为参数调用都会发生阻塞。例如，以阻塞模式的套接字为参数调用bind()、listen()函数时，函数会立即返回。将可能阻塞套接字的Windows Sockets API调用分为以下四种:
1．输入操作
recv()、recvfrom()、WSARecv()和WSARecvfrom()函数。以阻塞套接字为参数调用该函数接收数据。如果此时套接字缓冲区内没有数据可读，则调用线程在数据到来前一直睡眠。
2．输出操作
send()、sendto()、WSASend()和WSASendto()函数。以阻塞套接字为参数调用该函数发送数据。如果套接字缓冲区没有可用空间，线程会一直睡眠，直到有空间。
3．接受连接
accept()和WSAAcept()函数。以阻塞套接字为参数调用该函数，等待接受对方的连接请求。如果此时没有连接请求，线程就会进入睡眠状态。
4．外出连接
connect()和WSAConnect()函数。对于TCP连接，客户端以阻塞套接字为参数，调用该函数向服务器发起连接。该函数在收到服务器的应答前，不会返回。这意味着TCP连接总会等待至少到服务器的一次往返时间。
使用阻塞模式的套接字，开发网络程序比较简单，容易实现。当希望能够立即发送和接收数据，且处理的套接字数量比较少的情况下，使用阻塞模式来开发网络程序比较合适。
阻塞模式套接字的不足表现为，在大量建立好的套接字线程之间进行通信时比较困难。当使用“生产者-消费者”模型开发网络程序时，为每个套接字都分别分配一个读线程、一个处理数据线程和一个用于同步的事件，那么这样无疑加大系统的开销。其最大的缺点是当希望同时处理大量套接字时，将无从下手，其扩展性很差。
非阻塞模式
把套接字设置为非阻塞模式，即通知系统内核：在调用Windows Sockets API时，不要让线程睡眠，而应该让函数立即返回。在返回时，该函数返回一个错误代码。图所示，一个非阻塞模式套接字多次调用recv()函数的过程。前三次调用recv()函数时，内核数据还没有准备好。因此，该函数立即返回WSAEWOULDBLOCK错误代码。第四次调用recv()函数时，数据已经准备好，被复制到应用程序的缓冲区中，recv()函数返回成功指示，应用程序开始处理数据。
当使用socket()函数和WSASocket()函数创建套接字时，默认都是阻塞的。在创建套接字之后，通过调用ioctlsocket()函数，将该套接字设置为非阻塞模式。Linux下的函数是:fcntl().
套接字设置为非阻塞模式后，在调用Windows Sockets API函数时，调用函数会立即返回。大多数情况下，这些函数调用都会调用“失败”，并返回WSAEWOULDBLOCK错误代码。说明请求的操作在调用期间内没有时间完成。通常，应用程序需要重复调用该函数，直到获得成功返回代码。
需要说明的是并非所有的Windows Sockets API在非阻塞模式下调用，都会返回WSAEWOULDBLOCK错误。例如，以非阻塞模式的套接字为参数调用bind()函数时，就不会返回该错误代码。当然，在调用WSAStartup()函数时更不会返回该错误代码，因为该函数是应用程序第一调用的函数，当然不会返回这样的错误代码。
要将套接字设置为非阻塞模式，除了使用ioctlsocket()函数之外，还可以使用WSAAsyncselect()和WSAEventselect()函数。当调用该函数时，套接字会自动地设置为非阻塞方式。
由于使用非阻塞套接字在调用函数时，会经常返回WSAEWOULDBLOCK错误。所以在任何时候，都应仔细检查返回代码并作好对“失败”的准备。应用程序连续不断地调用这个函数，直到它返回成功指示为止。上面的程序清单中，在While循环体内不断地调用recv()函数，以读入1024个字节的数据。这种做法很浪费系统资源。
要完成这样的操作，有人使用MSG_PEEK标志调用recv()函数查看缓冲区中是否有数据可读。同样，这种方法也不好。因为该做法对系统造成的开销是很大的，并且应用程序至少要调用recv()函数两次，才能实际地读入数据。较好的做法是，使用套接字的“I/O模型”来判断非阻塞套接字是否可读可写。
非阻塞模式套接字与阻塞模式套接字相比，不容易使用。使用非阻塞模式套接字，需要编写更多的代码，以便在每个Windows Sockets API函数调用中，对收到的WSAEWOULDBLOCK错误进行处理。因此，非阻塞套接字便显得有些难于使用。
但是，非阻塞套接字在控制建立的多个连接，在数据的收发量不均，时间不定时，明显具有优势。这种套接字在使用上存在一定难度，但只要排除了这些困难，它在功能上还是非常强大的。通常情况下，可考虑使用套接字的“I/O模型”，它有助于应用程序通过异步方式，同时对一个或多个套接字的通信加以管理。