TCP/UDP简易通信框架源码,支持轻松管理多个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文件直接下载:https://files.cnblogs.com/files/xiaozhi_5638/TJSYXY.Communication.rar

posted @ 2015-07-22 12:09  周见智  阅读(17394)  评论(41编辑  收藏  举报