（转）TCP/UDP简易通信框架源码，支持轻松管理多个TCP服务端（客户端）、UDP客户端

目录

• 说明
• TCP/UDP通信主要结构
• 管理多个Socket的解决方案
• 框架中TCP部分的使用
• 框架中UDP部分的使用
• 框架源码结构
• 补充说明
• 源码地址

说明

之前有好几篇博客在讲TCP/UDP通信方面的内容，也有做过一些Demo（包括整理出来的、可供学习使用的简单通信框架）。具体可以参见以下博客：

http://www.cnblogs.com/xiaozhi_5638/p/4244797.html（清晰易懂TCP通信原理解析）

http://www.cnblogs.com/xiaozhi_5638/p/3290283.html（基于泵的TCP通信过程建立）

http://www.cnblogs.com/xiaozhi_5638/p/3169641.html（基于泵的UDP通信过程建立）

http://www.cnblogs.com/xiaozhi_5638/p/4528551.html（泵结构在系统中的作用）

可以看出，很多博客一直在强调“泵”（循环结构）在各个场合中的作用，若有不清楚泵结构的朋友，可以参见这篇博客“代码中的泵”。今天这次博客的重点并不是讲泵结构在通信过程中的应用，而是讲如何在同一进程中轻松快捷地创建多个TCP服务端（绑定多个Port）、多个TCP客户端（随意连接指定服务端）、多个UDP客户端（绑定多个Port），同时能够进行统一管理、访问。

在TCP通信开发过程中，经常会出现一个程序需要监听多个Port，或者一个程序需要连接多个TCP服务器（本人实际项目中遇到过），那么如何统一、方便管理创建的多个Socket呢？

如上图左边所示，一个程序需要同时访问两个Server，那么它至少要同时保持两个Socket连接。同理，一个服务程序很可能同时监听多个Port，需要管理多个侦听Socket。在UDP通信系统中（上图右边），一个程序也可能需要监听多个Port，同时接收多个Port上的数据。那么本文提供了一套可以轻松管理这些多个Socket的方案。

TCP/UDP通信主要结构

TCP服务端

一个TCP服务端主要包含两个结构：一个是Socket侦听循环（Socket侦听泵），一个便是数据接收循环（数据接收泵）。前者主要负责处理Socket连入请求，后者负责接收对应客户端发来的数据。下图显示的是一个TCP服务端包含的主要构造：

TCP客户端

一个TCP客户端主要包含一个结构：数据接收循环（数据接收泵）。客户端Socket连入服务器成功后，便需要开启数据接收循环，用于接收服务端发来的数据。下图显示的是一个TCP客户端包含的主要构造：

UDP客户端

一个UDP客户端主要包含一个结构：数据接收循环（数据接收泵）。客户端绑定本地Port成功后，便需要开启数据接收循环，用于接收来自绑定端口的数据。下图显示的是一个UDP客户端包含的主要构造：

注：

虽然UDP通信中的每个终端都是平等的（不存在主动连入和被动连入），但还是习惯上称每个终端为Client。虽然它包含的主要结构和TCP客户端类似（都只有一个数据接收循环），但是在TCP中，客户端Socket需要提前Connect到服务器，而通常情况下，UDP需要提前绑定本地端口。

管理多个Socket的解决方案

这里说到的Socket，在TCP服务端中指的是侦听Socket，在TCP客户端中指的是与服务端建立连接的Socket，而在UDP客户端中指的是绑定本地端口的Socket。这些Socket都可以存在多个，TCP服务端中可以有多个Socket侦听不同的Port，TCP客户端可以有多个Socket与不同的服务端建立连接，而UDP客户端中则可以有多个Socket绑定不同的端口。那么如何管理多个Socket呢？

答案其实很简单，可以将它们放进一个容器，统一通过容器管理、访问。那么怎样区分不同的Socket呢？我们可以给每个Socket加一个唯一标示（ID）。之后每次访问，均通过ID区分，只要给定ID，其余的操作均相同。这样一来，TCP服务端、TCP客户端以及UDP客户端的构造可以变成：

多个TCPServer：

多个TCPClient

多个UDPClient

每次访问，比如TCP服务端开启侦听、注册事件以及主动调用发送数据的API时，均可以通过容器代理进行操作，只需要给出指定的ID进行区分即可。

框架中TCP部分的用法

TCP服务端

框架公开了TCPServerManager、TCPEndPoint两个类型，前者主要负责代理操作的功能，所有对服务端的操作均通过它来完成；后者对应每个连接进来的客户端。

1）创建服务器

之后便可以使用manager操作创建好的服务器。注意如果这里已经存在ID为RegisterServer的服务器的话，manager就指代已经创建好的服务器。我们还可以创建第二服务器：

以上，只要给定的ID不同即可。

2）启动服务器

3）注册事件

以上分别注册客户端连接、断开以及发送消息的事件，之后便可以在事件处理方法中处理消息。

4）消息处理

当客户端发送消息时，系统会激发TCPMessageReceived事件，我们在事件处理程序中可以解析、处理消息：

在消息处理这块，框架简单地定义了一个“协议”：消息类型+消息正文。如果你觉得不够，完全可以在args.Data中再定义自己的协议。客户端上线、下线处理方式类似。这里不再赘述。

TCP客户端

框架公开了TCPClientManager类型，它主要负责代理操作的功能，所有对客户端的操作均通过它来完成。

1）创建客户端

以上创建了一个TCP客户端。如果给定的ID已存在，那么manager指代已经存在的客户端。同理，我们可以创建第二个客户端：

以上，只要给定的ID不同即可。

2）连接服务器

3）注册事件

以上注册消息事件，当收到服务端消息时会激发TCPMessageReceived事件。

4）消息处理

TCP客户端消息处理这块参见TCP服务端。原理类似。

框架中UDP部分的用法

UDP客户端

框架公开了UDPClientManager类型，主要负责代理操作的功能，对UDP客户端的所有操作均由它来完成。

1）创建客户端

以上创建了一个UDP客户端。如果给定的ID已存在，那么manager指代的是已经存在的UDP客户端。同理，我们可以创建第二个UDP客户端：

以上，只要给定的ID不存在即可。

2）监听端口

以上创建了两个不同的UDP客户端，分别监听不同的Port，接收不同的数据。

3）注册事件

以上注册了消息事件，当端口上有数据收到时会激发UDPMessageReceived事件。

4）消息处理

当UDP客户但收到消息时，系统会激发UDPMessageReceived事件，我们可以在事件处理程序中解析、处理消息：

注意UDP这块处理消息有一点与TCP不同，args参数中是以RemoteIP和RemotePort来表明消息发送方的信息，而TCP处理消息时，args参数中以TCPEndPoint来代表消息发送方的信息，后者包含的信息更全（不只有RemoteIP和RemotePort，具体参见源码）。

在消息处理这块，框架简单地定义了一个“协议”：消息类型+消息正文。如果你觉得不够，完全可以在args.Data中再定义自己的协议。

框架源码结构

.NET4.0  VS2010

对外公开的有TCPServerManager、TCPClientManager、TCPEndPoint、UDPClientManager以及Msg枚举类型。

补充说明

• TCP部分已解决沾包问题，附带心跳检测功能（有待完善）；
• 框架默认采用了一个简单的协议，用以区分发送消息的类型。我们在使用过程中，完全可以自定义应用层协议（再封装一层），并在收到数据后解析；
• TCP服务端的在线列表需要自己人工维护（上下线）；收到的消息数据都是byte[]类型，需要自己解析；而且不能注册自己想要的消息（必须全部接收）。由于我司主要开发局域网内网系统，对连接数量要求不是很高，我司实际使用中的通信框架经实体机房测试，连接数在400+，系统运行稳定。TCP部分发送3G大文件，不会出现内存异常等问题。
• 这次也是为了验证多个Socket管理的方案，所以才出了这个框架，由于时间仓促，所以仅供学习使用。若有人要应用到实际项目中去，可能需要修改完善一些地方，因为我并没有完全测试。

源码地址

源码中带有两个Demo。

github：https://github.com/sherlockchou86/TJSYXYCommunication

rar文件直接下载：http://files.cnblogs.com/files/xiaozhi_5638/TJSYXY.Communication.rar

作者：周见智 出处：http://www.cnblogs.com/xiaozhi_5638/ 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。