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的缺省方式，也是最常用的方式，即函数阻塞直到调用完毕。可参见前面的例子。 可能造成阻塞的函数有：connect()、accept()、读写函数、select()、poll()、gethostbyname()等。 　 非阻塞模式 程序调用可能造成阻塞的函数时，如果会发生阻塞，这些函数返回-1并将errno设置为EAGAIN或EWOULDBLOCK，程序可继续向下运行。可能阻塞的函数对应的任务完成，则再次调用该函数时就返回0表示运行结束。 非阻塞模式可以避免程序死锁，但是需要程序不断检查各个可能阻塞的函数的状态，当一个应用程序使用了非阻塞模式的套接字，它需要使用一个循环来不听的测试是否一个文件描述符有数据可读（称做polling）。应用程序不停的polling内核来检查是否I/O操作已经就绪。这将是一个极浪费CPU资源的操作，因此不能实际应用。一般非阻塞模式是与同步I/O模式共同使用的。 进入非阻塞模式的方法，请参见函数说明 　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模型”，它有助于应用程序通过异步方式，同时对一个或多个套接字的通信加以管理。