java长连接的实现.docVIP

梁应宏 引言 TCP长连接服务在传统的智能网应用中扮演着重要的角色。由于其传输的高效率，在智能网SCP和IP的各个模块之间，大量使用了这种服务。例如，SS7gateway与SCF、SCF与INES、INES与外部节点、CN与VN，等等。 相反，在各种WEB应用中，广泛使用TCP短连接服务。基于HTTP承载的各种应用协议，如HTML，XML，SOAP等，多数使用TCP短连接服务。原因有二：一是这些HTTP协议的数据包较大，传输所占的开销较大，连接建立的开销相对较小。此时使用长连接对性能的提升并不明显。二是相对于长连接而言，无论是对于客户端还是服务端，短连接的实现难度要低很多。 以网通水平业务平台SPGW为例，多数对外接口采用HTTP/XML/SOAP协议和短连接。然而，出于性能的考虑，还有两个接口采用TCP长连接： l 东向接口（SPGW-DSMP）：SCCP协议使用二进制消息。 l 南向接口（SPGW-SMSC）：SPGW与短消息网关SMSC之间的SM7协议使用二进制消息。 从Java开发语言的角度，短连接的使用比较简单。因为Java的IO库已经提供了一个httpConnection类，成熟可靠，使用方便。但是，对于TCP长连接的使用，Java的IO库并没有直接的支持。本文将探讨对TCP长连接服务的一般需求和我们的实现考虑。 以下也简称TCP长连接服务为TCP服务。 需求 具有网络编程经验的人都知道，TCP程序的编写是“易学难精”。很容易编写一个TCP程序，具有一定的功能并且在少数正常情况下可以运行。但是，要想让它在各种网络条件、各种负荷情况下都能稳定运行，却不是一件简单的工作。具体说来，TCP长连接服务需要满足以下条件： 高性能 实现这一点的关键是，消息的接收操作必须是异步的。以SPGW与短信网关之间的消息流程为例，如下： 如上图所示，SPGW可以不等待上一消息的应答消息，就发送下一个短消息。因此在同一个TCP connection上，SM7消息的接收必须是异步的，否则就会阻塞后续消息的发送。 健壮性 健壮性要求，TCP长连接服务不仅要能适应良好的网络情况和低负荷，而且要能适应差的网络情况和高负荷。实现这一点需要做到： l 应用级心跳：自动检测网络故障。 l 应用级重连：自动排除网络故障。 l 请求分发：需要将请求消息分发到消息队列或者独立的线程中，以免阻塞接收线程的工作。 l 统计与管理：可以查询统计TCP服务模块的工作情况。也可以通过某种标准的网络管理协议（如SNMP）来控制TCP连接的状态，如打开或者关闭。 应用友好性 l 同步的响应消息接收API：尽管TCP服务内部对消息的接收是异步的，但是，它需要向应用模块提供同步的响应消息接收API，以简化应用模块的开发。 l 明确的双向接口：一般的服务包只需要提供单向的API接口，由应用模块调用。但是，TCP服务包不同，除了被应用模块调用外，它还要对应用模块进行回调。例如，当接收到消息时，需要回调应用模块的方法，对消息进行定界和分发；在进行心跳检测时，需要回调应用模块的编解码方法。因此需要明确地定义TCP模块和应用模块之间的双向接口。 传统的实现方式 在我们以往的程序实现中，一般都是采用单connection，异步消息收发的方式。 Extra Node Application Main Thread Transceive Thread Message Queue 整个系统的逻辑结构大致如上。Application一般分为Main和Transceive两个线程。前者用于完成应用的逻辑，后者完成消息的收发。它们之间通过一个共享的Message Queue来通信。二者的流程使用伪码表示如下： Main Thread： while(true) 从Message Queue取输入消息 处理该消息（中间可能产生输出消息送到Message Queue） Transceive Thread： while(true) if(connection 可写) 从Message Queue取输出消息 将该消息写到connection if(connection 可读) 从connection读输入消息 将该消息送到Message Queue 对于Transceive Thread，判断connection是否可读写，是为了避免阻塞。这是通过socket API的select函数来完