CN102546437A - 一种面向物联网平台的套接字实现方法 - Google Patents

Abstract

一种面向物联网平台的套接字实现方法，面向物联网应用的服务器需要为大量并发连接提供高效，高可靠性的服务，同时通信层应当尽量减小***负荷。为此在物联网平台的通信层，利用缓冲池、线程池建立多线程并发连接，提出一种高效Socket服务器设计方案，在应对大量的用户和数据请求的同时，最大限度地减少***开销和缓存的使用。仿真结果表明，引入线程池和缓冲池的Socket服务器可减少线程的创建和销毁时间以及客户端阻塞时间，减少线程的动态生成和销毁过程，从而增强服务器的处理能力。

Description

一种面向物联网平台的套接字实现方法

技术领域

本发明是一种基于物联网平台的Socket(套接字)服务器的通信模块的设计与优化方案，属物联网的通信技术领域。

背景技术

随着物联网技术的不断发展，传感器、RFID(射频识别，Radio FrequencyIdentification)得到了广泛的应用。由感知层收集的数据将通过通信层传输到应用层，而这些数据的服务对象——用户，也要通过通信层对其进行访问。因此，作为整个***中枢的物联网平台，既要能够应对感知层收集的海量数据，又要能够处理大量用户对平台上各种应用的访问，通信层在其中的任务至关重要。设计完善的通信层可以轻松自如地应对海量的数据和访问请求，反之整个平台可能将发生灾难性的后果。

作为一种重要的进程通讯机制，Socket被广泛运用于一系列C/S(客户端/服务器，Client/Server)模式的通信场景中。为了应对数量巨大的连接，服务器端需要引入多线程技术并行处理每一个连接。如果每一个新连接都由动态创建的新线程进行处理，***性能将被极大地削弱。于是预先存放一些以创建线程的线程池技术应运而生，然而线程池的大小是否固定始终是一个值得研究的问题，静态规模的线程池节省了创建和销毁线程的开销，但对于远超其容量的连接数难以应对，简单地将池子的规模扩大，过多的空闲线程仍会占用不小的***资源；动态规模的线程池在面对大量连接时仍需不断地生成新线程，极大地增加了***负荷。因此应当根据***所处环境的不同进行分析，决定采用何种形式和多大容量的线程池。

目前国内外关于动态线程池的研究，主要集中在三个方面：(1)在突发连接较大时批量创建一些线程，而不是来一个请求才创建一个线程，但要控制池中线程数目的上限；(2)优化工作线程的数目，运用统计学原理预测高峰时段的用户数。这种策略相对简单，可靠性较高；(3)在一个服务器提供多个线程池，根据不同的任务和优先级采用不同的线程池处理。

发明内容

技术问题：本发明使用线程池技术构建了socket服务器，设计了***运行支撑方案，并对线程池的工作机制进行深入分析，计算了动态线程池在面临超过其容量的请求时的开销，提出使用缓冲池存储超量连接请求而不是动态生成额外线程的方案，然后对总体设计进行优化，应对常见的突发情况。

技术方案：动态线程池虽然得到了广泛应用，其局限性和优点一样明显，当大量超过其容量的连接请求同时出现，线程池动态生成与销毁线程的开销将不可忽略。因此在提出的socket服务器方案在线程池前加入了缓冲池接收超量线程，当线程池中出现空闲线程时从缓冲池中取出新的连接请求。

Socket服务器用于完成两个程序之间的网络通讯，服务器必须给出自己的IP(网络协议，Internet Protocol)地址和端口号，客户端向该地址的相应端口请求连接。具体过程为：

服务器端建立ServerSocket监听客户端的连接，收到请求后建立连接，并取出消息进行处理，将处理后的结果返回，客户端向服务器发送连接请求，建立连接后就向服务器发送或从服务器接收消息。

1.通信模块设计

该部分是socket服务器的核心，完成服务器最重要的通信功能。服务器端的通信模块组成基本设计方案为：

为了满足双工通信的要求，即服务器和客户端可以同时收发数据，需建立发送，接收两个线程，线程池中存放的是接收线程，在建立连接后该线程取出Socket连接，接收消息并通过接收消息队列传送至上层，同时建立发送线程，监听发送消息队列(与上层的接口，存放上层处理完的结果)，取出结果并发送。与此同时，接收线程处于阻塞状态，客户端请求断开，则关闭Socket连接。此外，为防止连接数过多，将超过池中线程数的连接放入缓冲池，等到出现空闲线程再取出。

2.线程池设计

定义1.线程技术中的两个主要开销是线程的建立和销毁，以及线程的维护。设第一种开销为C1，第二种开销为C2。

C1：线程的建立和销毁的开销，大部分是为线程分配内存的时间；

C2：线程的维护的开销，线程的上下文切换时间；

n：线程池大小；

r：当前运行的线程数。

实际情况中C1＞＞C2，表1对比了线程池的使用与否对于***性能的影响。

表1***引入线程池前后的开销对比

	线程池开销	没有线程池的开销	获得提升的***性能
				0≤r≤n	C2·n	C1·r	C1·r-C2·n
r＞n	C2·n+C1·(r-n)	C1·r	C1·n-C2·n

表1考虑了两种情况。当池中存活的线程数小于池的大小时(0≤r≤n)，在有线程池的情况下***的开销仅限于在各个线程之间进行切换，即C2·n。而没有线程池时***需要对每一个新连接创建并销毁线程，开销为C1·r，第一种方案将使得***性能提升C1·r-C2·n。

在第二种情况中，任务数超过了线程池的最大值，此时线程池必须为多余的任务创建新线程，开销为C2·n+C1·(r-n)，而没有线程池的开销依然为C1·r。前一种方案使得***性能提升了C1·n-C2·n。

第一种方案的关键问题是线程池大小的设置问题。如果池中线程数过多，***为了维护这些空闲线程需要消耗大量的处理和缓存资源，线程数过少则导致必须不断地动态地生成新线程并在任务结束之后销毁，付出的代价可能超过任务本身所消耗的资源。下面对如何确定最佳线程数(n)进行讨论。

定义2.实际环境中线程池中存活的线程是在不断变化的，设r为存活的线程数，f(r)为其分布律，线程池大小n的期望为：

$E\left(n\right)=\underset{r=0}{\overset{n}{\mathrm{\Σ}}}(C_1\·r-C_2\·n)\·f\left(r\right)+\underset{r=n+1}{\overset{\∞}{\mathrm{\Σ}}}(C_1\·n-C_2\·n)\·f\left(r\right)---\left(1\right)$

设最佳线程池大小为n^*，其期望为：

$E\left(n^{*}\right)=\underset{n\∈N}{\sup }E\left(n\right)---\left(2\right)$

N代表线程池中线程数的集合，

表示E(n)的取值上界。将(1)改写成如下形式，p(r)为线程池中存活的线程数的概率密度函数：

$E\left(n\right)={\∫}_0^n(C_1\·r-C_2\·n)\·p\left(r\right)\mathrm{dr}+{\∫}_n^{\∞}(C_1\·n-C_2\·n)\·p\left(r\right)\mathrm{dr}---\left(3\right)$

为了得到E(n)的最大值，对(3)进行求导，得(4)：

$\frac{\mathrm{dE}}{\mathrm{dn}}=-C_2+C_1\·{\∫}_0^{\∞}p\left(r\right)\mathrm{dr}=0---\left(4\right)$

改写(4)，设维持运行线程与创建新线程的比率为ξ＝C₂/C₁：

${\∫}_{n*}^{\∞}p\left(r\right)\mathrm{dr}=\mathrm{\ξ}$ ${\∫}_0^{n*}p\left(r\right)\mathrm{dr}\≤1-\mathrm{\ξ}---\left(5\right)$

由于线程池大小为整数，所以该值由下式确定：

${\∫}_0^{n^{*}}p\left(r\right)\mathrm{dr}\≤1-\mathrm{\ξ}$ ${\∫}_0^{n^{*}+1}p\left(r\right)\mathrm{dr}>1-\mathrm{\ξ}---\left(6\right)$

该式表明n^*与ξ有关，当线程切换的开销远小于线程创建与销毁的开销时，线程池的容量更大。(5)(6)也表明n^*与***当前负载p(r)有关。

本发明的一种面向物联网平台的Socket设计与优化方案在物联网平台的通信层，利用缓冲池、线程池建立多线程并发连接，提出一种高效Socket服务器设计方案，在应对大量的用户和数据请求的同时，最大限度地减少***开销和缓存的使用；使用线程池技术构建了socket服务器，设计了***运行支撑方案，并对线程池的工作机制进行深入分析，计算了动态线程池在面临超过其容量的请求时的开销，提出使用缓冲池存储超量连接请求而不是动态生成额外线程的方案，然后对总体设计进行优化，应对常见的突发情况。

所述的使用线程池技术构建了socket服务器，包括通信模块设计和线程池设计，动态线程池虽然得到了广泛应用，其局限性和优点一样明显，当大量超过其容量的连接请求同时出现，线程池动态生成与销毁线程的开销将不可忽略。因此在提出的socket服务器方案在线程池前加入了缓冲池接收超量线程，当线程池中出现空闲线程时从缓冲池中取出新的连接请求。

Socket服务器用于完成两个程序之间的网络通讯，服务器必须给出自己的IP地址和端口号，客户端向该地址的相应端口请求连接。具体过程为：

服务器端建立ServerSocket监听客户端的连接，收到请求后建立连接，并取出消息进行处理，将处理后的结果返回，客户端向服务器发送连接请求，建立连接后就向服务器发送或从服务器接收消息。

通信模块设计是socket服务器的核心，完成服务器最重要的通信功能。服务器端的通信模块组成基本设计方案为：

为了满足双工通信的要求，即服务器和客户端可以同时收发数据，需建立发送，接收两个线程，线程池中存放的是接收线程，在建立连接后该线程取出Socket连接，接收消息并通过接收消息队列传送至上层，同时建立发送线程，监听发送消息队列(与上层的接口，存放上层处理完的结果)，取出结果并发送。与此同时，接收线程处于阻塞状态，客户端请求断开，则关闭Socket连接。此外，为防止连接数过多，将超过池中线程数的连接放入缓冲池，等到出现空闲线程再取出。

线程池设计即线程池大小的确定。线程池设计中的两个主要开销是线程的建立和销毁，以及线程的维护。设第一种开销为C1，第二种开销为C2。C1大部分是为线程分配内存的时间，C2则是线程的上下文切换时间。实际情况中C1＞＞C2。实际环境中线程池中存活的线程是在不断变化的，设r为存活的线程数(即线程池大小)，f(r)为其分布律，线程池大小n的期望为：

$E\left(n\right)=\underset{r=0}{\overset{n}{\mathrm{\Σ}}}(C_1\·r-C_2\·n)\·f\left(r\right)+\underset{r=n+1}{\overset{\∞}{\mathrm{\Σ}}}(C_1\·n-C_2\·n)\·f\left(r\right)---\left(1\right)$

设最佳线程池大小为n^*，其期望为：

$E\left(n^{*}\right)=\underset{n\∈N}{\sup }E\left(n\right)---\left(2\right)$

N代表线程池中线程数的集合，

表示E(n)的取值上界。将(1)改写成如下形式，p(r)为线程池中存活的线程数的概率密度函数

$E\left(n\right)={\∫}_0^n(C_1\·r-C_2\·n)\·p\left(r\right)\mathrm{dr}+{\∫}_n^{\∞}(C_1\·n-C_2\·n)\·p\left(r\right)\mathrm{dr}---\left(3\right)$

为了得到E(n)的最大值，对(3)进行求导，得(4)：

$\frac{\mathrm{dE}}{\mathrm{dn}}=-C_2+C_1\·{\∫}_0^{\∞}p\left(r\right)\mathrm{dr}=0---\left(4\right)$

改写(4)，设维持运行线程与创建新线程的比率为ξ＝C₂/C₁：

${\∫}_{n*}^{\∞}p\left(r\right)\mathrm{dr}=\mathrm{\ξ}$ ${\∫}_0^{n*}p\left(r\right)\mathrm{dr}\≤1-\mathrm{\ξ}---\left(5\right)$

由于线程池大小为整数，所以该值由下式确定：

${\∫}_0^{n^{*}}p\left(r\right)\mathrm{dr}\≤1-\mathrm{\ξ}$ ${\∫}_0^{n^{*}+1}p\left(r\right)\mathrm{dr}>1-\mathrm{\ξ}---\left(6\right)$

该式表明n^*与ξ有关，当线程切换的开销远小于线程创建与销毁的开销时，线程池的容量更大。公式(5)(6)也表明n^*与***当前负载p(r)有关。

对***负载能力进行评估时，假设p(r)为均匀分布，用户数量为4000，又因为***创建销毁线程约为400ms，上下文切换约为20ms，

则有

n^*＝3600。

所述的***运行支撑方案为***使用自定协议，客户端和服务器发送和接收数据包进行通信，数据包大小为约为100Bytes。***处理消息后以数据包的形式将消息返回。为了达到双工，设定发送与接收两条线程，并且发送线程是接收线程的子线程。服务器收到的消息放入接收消息队列交由业务层处理。当业务层处理完毕，各个线程去发送消息队列取出属于自己的处理结果然后发送。

所述的常见的突发情况是1)如何标记不同客户端的任务2)接收数据时可能有阻塞3)Socket关闭后仍进行读写操作4)客户端意外断开四种情况。

所述的如何标记不同客户端的任务，解决方案是：对于该情况，因为每个任务都属于不同的客户端，因此可以从属于该客户端的Socket对象中获得其IP地址和端口号，设定存放客户端的IP和端口号的Mark字段，值为连接的IP和端口号。While循环中，每个任务所在的线程轮询消息队列(MessageQueue)最顶上的元素，一旦发现对应的Mark就取出其中的消息。否则线程挂起。

所述的接收数据时可能有阻塞是整个***中，客户端点击界面，程序发送数据包至服务器，然后由服务器完成相应的功能，因此任务的特点是对CPU的占用率低，但是经常会阻塞的I/O(输入/输出，Input/Output)操作。如果用户长时间不点击界面，线程池中的工作线程将被该用户始终占用，无法执行任何任务。如果线程池中所有线程都处于阻塞状态，则新加入的任务无法被处理。并且发送端数据量过大时收端可能无法完全接收。

解决方案是：定义nIdx，nTotalLen和nReadLen三个变量(nIdx用于存放总共读到的字节数，nTotalLen是总共要读取的字节数和nReadLen是已一次循环中读到的字节数)，nTotalLen的值可由包头的字段决定。While循环持续到读到输入流末尾跳出。为了避免忙等待这种不健康的使用CPU的方式，这里第二个while循环负责将没有数据输入的线程挂起，有输入时再唤醒。

所述的Socket关闭后仍进行读写操作，解决方案是：由于Socket的关闭受接收线程控制，因此可能在发送线程运行完成之前接收线程就将Socket关闭了。设立通知机制，让发送线程执行完毕后发送一个通知给接收线程，然后接收线程将Socket关闭可以解决该问题，即添加协议字段PacSeq(PacSeq为收到的请求包的编号)，例如接收线程收到PacSeq＝x的包，当发送线程发回该请求包所需结果后发送通知给接收线程，接收线程在收到该通知一直保持Socket连接状态。

所述的客户端意外断开，解决方案是：客户端每隔5分钟发送一次心跳包，服务器端由接收线程创建一个守护线程负责监测该心跳包并进行倒计时，接收线程收到心跳包不进行处理，只是发送通知给守护线程将计时器重置，然后继续保持与客户端连接。如果5分钟服务器没有收到，则守护线程发送通知，唤醒接收线程，由接收线程关闭socket。因为在倒计时阶段，三个线程都处于挂起状态，所以不占用***资源。客户端在发出请求后一定时间没收到反馈或出现异常则认定服务器断开。断开后重新发送连接请求。

有益效果：本发明针对物联网带来的海量需求，利用socket设计了服务器通信模块，深入研究了线程池的设置对***性能的影响，使用缓冲队列处理超出线程池容量的线程，分析***可能遇到的问题并进行优化。最后对***性能进行仿真，结果表明线程池配合缓冲池可以在面对一定程度上过量的连接时大大降低***开销，对于开销不大的任务不宜采用短连接模式，并且发现虽然超过线程池容量的连接数不大时使用缓冲池可以降低***开销，但一旦达到或超过某个阈值，***的反应时间将急剧上升。

附图说明

图1是Socket建立过程，

图2是通信模块运行流图，

图3是避免Socket关闭异常流程图，

图4是心跳监测流程图，

图5是实验1的socket连接速度对比图，

图6是实验2***BT性能柱状图，

图7是实验2***DT性能柱状图，

图8是实验2***DQL性能柱状图，

图9是实验2***DBT性能柱状图，

图10是实验3***反应时间的对比图。

具体实施方式

***运行支撑方式

***使用自定协议，客户端和服务器发送和接收数据包进行通信，数据包大小为约为100Bytes。***处理消息后以数据包的形式将消息返回。为了达到双工，设定发送与接收两条线程，并且发送线程是接收线程的子线程。服务器收到的消息放入接收消息队列交由业务层处理。当业务层处理完毕，各个线程去发送消息队列取出属于自己的处理结果然后发送。这里将会出现四种情况，解决方案如下：

情况一：如何标记不同客户端的任务。

解决方案：对于该情况，因为每个任务都属于不同的客户端，因此可以从属于该客户端的Socket对象中获得其IP地址和端口号，设定Mark字段，值为连接的IP和端口号。While循环中，每个任务所在的线程轮询消息队列(MessageQueue)最顶上的元素，一旦发现对应的Mark就取出其中的消息。否则线程挂起。

情况二：接收数据时可能有阻塞

解决方案：整个***中，客户端点击界面，程序发送数据包至服务器，然后由服务器完成相应的功能，因此任务的特点是对CPU的占用率低，但是经常会阻塞的I/O操作。如果用户长时间不点击界面，线程池中的工作线程将被该用户始终占用，无法执行任何任务。如果线程池中所有线程都处于阻塞状态，则新加入的任务无法被处理。并且发送端数据量过大时收端可能无法完全接收。

解决该问题可以定义nIdx，nTotalLen和nReadLen三个变量，分别存放总共读到的字节数，总共要读取的字节数和已一次循环中读到的字节数，nTotalLen的值可由包头的字段决定。While循环持续到读到输入流末尾跳出。为了避免忙等待这种不健康的使用CPU的方式，这里第二个while循环负责将没有数据输入的线程挂起，有输入时再唤醒。

情况三：Socket关闭后仍进行读写操作

解决方案：由于Socket的关闭受接收线程控制，因此可能在发送线程运行完成之前接收线程就将Socket关闭了。设立通知机制，让发送线程执行完毕后发送一个通知给接收线程，然后接收线程将Socket关闭可以解决该问题。如图3所示，添加协议字段PacSeq，将收到的请求包进行编号，例如接收线程收到PacSeq＝x的包，当发送线程发回该请求包所需结果后发送通知给接收线程，接收线程在收到该通知一直保持Socket连接状态。

情况四：客户端意外断开

解决方案：该问题可通过如图4所示的算法加以解决：客户端每隔5分钟发送一次心跳包，服务器端由接收线程创建一个守护线程负责监测该心跳包并进行倒计时，接收线程收到心跳包不进行处理，只是发送通知给守护线程将计时器重置，然后继续保持与客户端连接。如果5分钟服务器没有收到，则守护线程发送通知，唤醒接收线程，由接收线程关闭socket。因为在倒计时阶段，三个线程都处于挂起状态，所以不占用***资源。客户端在发出请求后一定时间没收到反馈或出现异常则认定服务器断开。断开后重新发送连接请求。

我们使用LoadRunner软件进行仿真测试。LoadRunner是一种预测***行为和性能的负载测试工具。软件能生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。实验中搭建了一台socket服务器，基本配置为双核2.4GHz，4GB内存。数据库采用Oracle 11G。

实验1考察了建立socket连接所需的时间，实验2分析在连接数4000，而线程池容量为3600时，***动态地为超量连接生成新线程时的性能，实验3在实验2的基础上引入缓冲池，然后观察***性能变化。

实验1：socket连接速度测试

Socket在建立连接时需要花费较多时间，如果服务器采用短连接模式，则连接本身所花时间可能不能忽略。为验证socket连接速度，生成一百个虚拟用户对服务器进行连接请求，客户端程序共进行两个动作：

1)尝试与服务器建立连接。

2)连接成功后发送一个数据包并显示服务器的反馈信息。服务器端也进行两个动作：1.监听客户端连接请求。2.连接成功后发回客户端发来的数据包。

虚拟用户在实验中的运行情况如图5所示。图5表明用户建立连接的速度，纵轴是虚拟用户的数目，横轴是运行时间。蓝线代表正在运行的虚拟用户数量，绿线代表已经执行完毕的虚拟用户数量。这里看出从第一个用户开始连接到最后一个用户执行完毕总共花了5秒，而大部分用户在连接成功之后是从第四秒开始发送数据的，也就是说连接花了整套操作五分之四的时间。

该实验表明在任务本身开销不大而类似任务可能频繁出现的情况下，服务器与客户端不应使用短连接模式，即每个完成之后应当保持连接一段时间，以避免频繁断开再建立连接所带来的额外开销。

实验2：服务器各性能参数对比测试

为了验证连接数超过线程池容量后，***动态生成新线程对性能造成的影响，在线程池与监听连接的accept方法之间设立缓冲池，将多余的连接存入池中，当线程池有空余线程时从池中取出连接运行。

分别考察在加入与没有加入缓冲池的情况下，***面对超过线程池容量的连接时的性能。共进行四次实验，将线程池设置为3600，每次的连接数分别设为3600，3800，4000，4200。***在没有加入缓冲池时为超过线程池容量的请求动态生成新线程。为了了解服务器的内存以及硬盘情况，观察表2中的参数：

表2服务器性能参数

本次实验内容与实验1相同，但为了加大服务器端压力，将整个过程迭代进行，即客户端完成操作后断开，然后再次请求连接，进行相同操作。整个过程持续五分钟。实验结果如图6所示。图6是***在上述条件下网络吞吐量(BT)的表现，在连接数等于线程池容量时有无缓冲池对网络吞吐量影响不大，当连接数上升到3800时由于有缓冲池的***不用实时创建线程，资源主要用在数据传输上，因此网络吞吐量比无缓冲池的***高。当连接数升到四千时两者吞吐量基本持平，而达到4200个连接后无缓冲池***的网络吞吐量比有缓冲池***的网络吞吐量高出将近25％，说明有缓冲池的***在面对过多连接时处理效率无法提升太多。

图7到图9显示的是缓冲池加入前后***硬盘运行状况的变化，可以看出加入缓冲池前***的DT、DQL、DBT开销随着连接数的增大而增大，在4200个连接时的表现比初始3600个连接分别上升了26.6％，20.3％，45.9％。这主要是因为***在不断实时生成与销毁线程，并且运行的线程总数也越来越多，消耗了大量的内存资源，***不得不使用磁盘作为虚拟内存，硬盘的负担也随之增大。反观加入缓冲池之后，虽然面对4200个连接时***吞吐量不尽如人意，但***开销基本保持平稳，这是因为运行的线程数减少使得线程切换的开销减少，并且由于将超过线程池容量的请求存入缓冲池，无需动态的生成与销毁线程，大大减少了***负荷。

由此可见，对于超过线程池容量但数量不多的连接应当将其放入缓冲池而不是动态生成线程进行处理，否则会造成***性能急剧下降，因为线程的创建与销毁的开销远大于维护线程时上下文切换的开销。为了增大连接数而贸然增大线程数虽然可以增强处理能力，却很可能导致***性能下降。在整个过程中应当尽量避免对硬盘的操作，因为该操作会极大地拖慢***运行效率。

实验3：***响应时间对比测试

实验2表明将超出线程池容量的连接放在缓存池中，等待空闲线程出现在进行处理可以降低***开销。但在连接数过大时***对新连接反应较慢，新用户可能需要等待较长时间才能连接成功，为寻找***反应时间的拐点，重复上述实验内容，不断增大连接请求数，观察***反应时间，结果如图10所示。图10横轴代表***承受的并发连接数，纵轴代表***对连接请求的反应时间，可以看出连接请求数在3600时，有无缓冲池对***性能影响不大，因为此时没有新线程生成。在请求数为3800时有缓冲池的***反应时间较短，因为新连接在池中等待的时间比创建新线程的时间要少。但连接请求数达到4000时，有缓冲池的***的反应时间急剧增大至497ms，并且这种增长是非线性的，即不与连接数成正比，而无缓冲池的***反应时间几乎没有变化，维持在422ms。这是因为创建新线程只会增加***开销，而对每个任务的处理速度并没有降低。当连接数达到4200时，有缓冲池的***反应时间为885ms，已经大大高于了无缓冲池的***反应时间442ms。

发明点1、使用线程池技术构建socket服务器

通信模块设计

为了满足双工通信的要求，即服务器和客户端可以同时收发数据，需建立发送，接收两个线程，图2的线程池中存放的是接收线程，在建立连接后该线程取出Socket连接，接收消息并通过接收消息队列传送至上层，同时建立发送线程，监听发送消息队列(与上层的接口，存放上层处理完的结果)，取出结果并发送。与此同时，接收线程处于阻塞状态，客户端请求断开，则关闭Socket连接。此外，为防止连接数过多，将超过池中线程数的连接放入缓冲池，等到出现空闲线程再取出。

线程池设计

线程池设计中的两个主要开销是线程的建立和销毁，以及线程的维护。设第一种开销为C1，第二种开销为C2。C1大部分是为线程分配内存的时间，C2则是线程的上下文切换时间。实际情况中C1＞＞C2。实际环境中线程池中存活的线程是在不断变化的，设r为存活的线程数(即线程池大小)，f(r)为其分布律，线程池大小n的期望为：

$E\left(n\right)=\underset{r=0}{\overset{n}{\mathrm{\Σ}}}(C_1\·r-C_2\·n)\·f\left(r\right)+\underset{r=n+1}{\overset{\∞}{\mathrm{\Σ}}}(C_1\·n-C_2\·n)\·f\left(r\right)---\left(1\right)$

设最佳线程池大小为n^*，其期望为：

$E\left(n^{*}\right)=\underset{n\∈N}{\sup }E\left(n\right)---\left(2\right)$

N代表线程池中线程数的集合，

表示E(n)的取值上界。将(1)改写成如下形式，p(r)为线程池中存活的线程数的概率密度函数

$E\left(n\right)={\∫}_0^n(C_1\·r-C_2\·n)\·p\left(r\right)\mathrm{dr}+{\∫}_n^{\∞}(C_1\·n-C_2\·n)\·p\left(r\right)\mathrm{dr}---\left(3\right)$

为了得到E(n)的最大值，对(3)进行求导，得(4)：

$\frac{\mathrm{dE}}{\mathrm{dn}}=-C_2+C_1\·{\∫}_0^{\∞}p\left(r\right)\mathrm{dr}=0---\left(4\right)$

改写(4)，设维持运行线程与创建新线程的比率为ξ＝C₂/C₁：

${\∫}_{n*}^{\∞}p\left(r\right)\mathrm{dr}=\mathrm{\ξ}$ ${\∫}_0^{n*}p\left(r\right)\mathrm{dr}\≤1-\mathrm{\ξ}---\left(5\right)$

由于线程池大小为整数，所以该值由下式确定：

${\∫}_0^{n^{*}}p\left(r\right)\mathrm{dr}\≤1-\mathrm{\ξ}$ ${\∫}_0^{n^{*}+1}p\left(r\right)\mathrm{dr}>1-\mathrm{\ξ}---\left(6\right)$

该式表明n^*与ξ有关，当线程切换的开销远小于线程创建与销毁的开销时，线程池的容量更大。(5)(6)也表明n^*与***当前负载p(r)有关。

对***负载能力进行评估时，假设p(r)为均匀分布，用户数量为4000，又因为***创建销毁线程约为400ms，上下文切换约为20ms，

则有

n^*＝3600。

发明点2、解决如何标记不同客户端的任务的问题

对于该情况，因为每个任务都属于不同的客户端，因此可以从属于该客户端的Socket对象中获得其IP地址和端口号，设定Mark字段，值为连接的IP和端口号。While循环中，每个任务所在的线程轮询消息队列MessageQueue最顶上的元素，一旦发现对应的Mark就取出其中的消息。否则线程挂起。

发明点3、解决接收数据时可能有阻塞的问题

整个***中，客户端点击界面，程序发送数据包至服务器，然后由服务器完成相应的功能，因此任务的特点是对CPU的占用率低，但是经常会阻塞的I/O操作。如果用户长时间不点击界面，线程池中的工作线程将被该用户始终占用，无法执行任何任务。如果线程池中所有线程都处于阻塞状态，则新加入的任务无法被处理。并且发送端数据量过大时收端可能无法完全接收。

解决该问题可以定义nIdx，nTotalLen和nReadLen三个变量，分别存放总共读到的字节数，总共要读取的字节数和已一次循环中读到的字节数，nTotalLen的值可由包头的字段决定。While循环持续到读到输入流末尾跳出。为了避免忙等待这种不健康的使用CPU的方式，这里第二个while循环负责将没有数据输入的线程挂起，有输入时再唤醒。

发明点4、解决Socket关闭后仍进行读写操作的问题

由于Socket的关闭受接收线程控制，因此可能在发送线程运行完成之前接收线程就将Socket关闭了。设立通知机制，让发送线程执行完毕后发送一个通知给接收线程，然后接收线程将Socket关闭可以解决该问题。如图3所示，添加协议字段PacSeq，将收到的请求包进行编号，例如接收线程收到PacSeq＝x的包，当发送线程发回该请求包所需结果后发送通知给接收线程，接收线程在收到该通知一直保持Socket连接状态。

发明点5、解决客户端意外断开的问题

该问题可通过如图4所示的算法加以解决：客户端每隔5分钟发送一次心跳包，服务器端由接收线程创建一个守护线程负责监测该心跳包并进行倒计时，接收线程收到心跳包不进行处理，只是发送通知给守护线程将计时器重置，然后继续保持与客户端连接。如果5分钟服务器没有收到，则守护线程发送通知，唤醒接收线程，由接收线程关闭socket。因为在倒计时阶段，三个线程都处于挂起状态，所以不占用***资源。客户端在发出请求后一定时间没收到反馈或出现异常则认定服务器断开。断开后重新发送连接请求。

Claims (10)

1.一种面向物联网平台的套接字实现方法，其特征在于在物联网平台的通信层，利用缓冲池、线程池建立多线程并发连接，提出一种高效套接字服务器设计方法，具体如下：

1)使用线程池技术构建套接字服务器；

2)设计***运行支撑方案；

3)深入分析线程池的工作机制，计算动态线程池在面临超过其容量的请求时的开销，提出使用缓冲池存储超量连接请求；

4)对总体设计进行优化，应对常见的突发情况。

2.根据权利要求1所述的一种面向物联网平台的套接字实现方法，其特征在于所述的使用线程池技术构建套接字服务器，包括通信模块设计和线程池设计，本方法在线程池前加入了缓冲池接收超量线程，当线程池中出现空闲线程时从缓冲池中取出新的连接请求，套接字服务器用于完成两个程序之间的网络通讯，服务器必须给出自己的IP地址和端口号，客户端向该地址的相应端口请求连接；具体过程为：服务器端建立服务器套接字监听客户端的连接，收到请求后建立连接，并取出消息进行处理，将处理后的结果返回，客户端向服务器发送连接请求，建立连接后就向服务器发送或从服务器接收消息。

3.根据权利要求1所述的一种面向物联网平台的套接字实现方法，其特征在于所述的***运行支撑方案是：***使用自定协议，客户端和服务器发送和接收数据包进行通信，数据包大小为约为100Bytes；***处理消息后以数据包的形式将消息返回；为了达到双工，设定发送与接收两条线程，并且发送线程是接收线程的子线程；服务器收到的消息放入接收消息队列交由业务层处理，当业务层处理完毕，各个线程去发送消息队列取出属于自己的处理结果然后发送。

4.根据权利要求1所述的一种面向物联网平台的套接字实现方法，其特征在于所述的常见的突发情况是1)如何标记不同客户端的任务；2)接收数据时可能有阻塞；3)Socket关闭后仍进行读写操作；4)客户端意外断开四种情况。

5.根据权利要求2所述的一种面向物联网平台的套接字实现方法，其特征在于所述的通信模块设计，基本设计方案为：

为了满足双工通信的要求，即服务器和客户端同时收发数据，需建立发送，接收两个线程，线程池中存放的是接收线程，在建立连接后该线程取出Socket连接，接收消息并通过接收消息队列传送至上层，同时建立发送线程，监听发送消息队列，即与上层的接口，存放上层处理完的结果，取出结果并发送；与此同时，接收线程处于阻塞状态，客户端请求断开，则关闭Socket连接；此外，为防止连接数过多，将超过池中线程数的连接放入缓冲池，等到出现空闲线程再取出。

6.根据权利要求2所述的一种面向物联网平台的套接字实现方法，其特征在于所述的线程池设计，关键问题是线程池大小的设置问题，最佳线程池大小n^*的确定方法如下：

线程技术中的两个主要开销是线程的建立和销毁，以及线程的维护。设第一种开销为C1，第二种开销为C2，C1大部分是为线程分配内存的时间，C2则是线程的上下文切换时间；实际情况中C1＞＞C2，假设线程池大小为n，n为定值，当前运行的线程数为r，分别考虑线程池的使用与否对于***性能的影响：

1)当池中存活的线程数小于池的大小时，0≤r≤n，在有线程池的情况下***的开销仅限于在各个线程之间进行切换，即C2·n；而没有线程池时***需要对每一个新连接创建并销毁线程，开销为C1·r，使用线程池的方案将使得***性能提升C1·r-C2·n；

2)当池中存活的线程数大于池的大小时，r＞n，任务数超过了线程池的最大值，此时线程池必须为多余的任务创建新线程，开销为C2·n+C1·(r-n)，而没有线程池的开销依然为C1·r；使用线程池的方案使得***性能提升了C1·n-C2·n。

实际环境中线程池中存活的线程是在不断变化的，设变量r为当前运行的线程数，f(r)为其分布律，线程池大小n的期望为：

$E\left(n\right)=\underset{r=0}{\overset{n}{\mathrm{\Σ}}}(C_1\·r-C_2\·n)\·f\left(r\right)+\underset{r=n+1}{\overset{\∞}{\mathrm{\Σ}}}(C_1\·n-C_2\·n)\·f\left(r\right)---\left(1\right)$

设最佳线程池大小为n^*，其期望为：

$E\left(n^{*}\right)=\underset{n\∈N}{\sup }E\left(n\right)---\left(2\right)$

N表示线程池中线程数的所有可能取值的集合，

表示E(n)的取值上界，将(1)改写成如下形式，p(r)为线程池中存活的线程数的概率密度函数

$E\left(n\right)={\∫}_0^n(C_1\·r-C_2\·n)\·p\left(r\right)\mathrm{dr}+{\∫}_n^{\∞}(C_1\·n-C_2\·n)\·p\left(r\right)\mathrm{dr}---\left(3\right)$

为了得到E(n)的最大值，对(3)进行求导，得式(4)：

$\frac{\mathrm{dE}}{\mathrm{dn}}=-C_2+C_1\·{\∫}_0^{\∞}p\left(r\right)\mathrm{dr}=0---\left(4\right)$

改写(4)，设维持运行线程与创建新线程的比率为ξ＝C₂/C₁：

${\∫}_{n*}^{\∞}p\left(r\right)\mathrm{dr}=\mathrm{\ξ}$ ${\∫}_0^{n*}p\left(r\right)\mathrm{dr}\≤1-\mathrm{\ξ}---\left(5\right)$

由于线程池大小为整数，所以该值由下式确定：

${\∫}_0^{n^{*}}p\left(r\right)\mathrm{dr}\≤1-\mathrm{\ξ}$ ${\∫}_0^{n^{*}+1}p\left(r\right)\mathrm{dr}>1-\mathrm{\ξ}---\left(6\right)$

该式表明n^*与ξ有关，当线程切换的开销远小于线程创建与销毁的开销时，线程池的容量更大；式(5)式(6)也表明n^*与***当前负载p(r)有关。

7.根据权利要求5所述的一种面向物联网平台的套接字实现方法，其特征在于所述的如何标记不同客户端的任务，其解决方案是：对于该情况，因为每个任务都属于不同的客户端，因此从属于该客户端的Socket对象中获得其IP地址和端口号，设定存放客户端的IP和端口号的Mark字段，值为连接的IP和端口号；While循环中，每个任务所在的线程轮询消息队列MessageQueue最顶上的元素，一旦发现对应的Mark就取出其中的消息，否则线程挂起。

8.根据权利要求5所述的一种面向物联网平台的套接字设计方法，其特征在于所述的接收数据时可能有阻塞，是整个***中，客户端点击界面，程序发送数据包至服务器，然后由服务器完成相应的功能，因此任务的特点是对CPU的占用率低，但是经常会阻塞的I/O操作；如果用户长时间不点击界面，线程池中的工作线程将被该用户始终占用，无法执行任何任务；如果线程池中所有线程都处于阻塞状态，则新加入的任务无法被处理，并且发送端数据量过大时收端可能无法完全接收。

解决方案是：定义nIdx，nTotalLen和nReadLen三个变量，nIdx用于存放总共读到的字节数，nTotalLen是总共要读取的字节数和nReadLen是已一次循环中读到的字节数；nTotalLen的值可由包头的字段决定，While循环持续到读到输入流末尾跳出，为了避免忙等待这种不健康的使用CPU的方式，这里第二个while循环负责将没有数据输入的线程挂起，有输入时再唤醒。

9.根据权利要求5所述的一种面向物联网平台的套接字设计方法，其特征在于所述的Socket关闭后仍进行读写操作，解决方案是：由于Socket的关闭受接收线程控制，因此可能在发送线程运行完成之前接收线程就将Socket关闭了；设立通知机制，让发送线程执行完毕后发送一个通知给接收线程，然后接收线程将Socket关闭可以解决该问题，即添加协议字段PacSeq，PacSeq为收到的请求包的编号，当发送线程发回该请求包所需结果后发送通知给接收线程，接收线程在收到该通知一直保持Socket连接状态。

10.根据权利要求5所述的一种面向物联网平台的套接字设计方法，其特征在于所述的客户端意外断开，解决方案是：客户端每隔5分钟发送一次心跳包，服务器端由接收线程创建一个守护线程负责监测该心跳包并进行倒计时，接收线程收到心跳包不进行处理，只是发送通知给守护线程将计时器重置，然后继续保持与客户端连接；如果5分钟服务器没有收到，则守护线程发送通知，唤醒接收线程，由接收线程关闭socket；因为在倒计时阶段，三个线程都处于挂起状态，所以不占用***资源，客户端在发出请求后一定时间没收到反馈或出现异常则认定服务器断开，断开后重新发送连接请求。

Images