系统会在后台产生一个后台进程，该进程是TongLinkQ守护进程，也是TongLinkQ的系统核心，主要负责数据的收发、控制端对端消息的传输以及监控网络的运行状况。

TONGLINK/Q介绍

TongLink/Q的基本运行单位：节点。

每个节点都有一个节点名称，节点名称由英文字母、.、下划线、数字组成，但必须以英文字母打头，长度不得超过20个字符。

每个节点对应一个IP地址，节点名配置在hosts文件中。

节点间的连接通过TongLinkQ间虚拟的数据通道。

TongLinkQ节点启动：系统会在后台产生一个后台进程，该进程是TongLinkQ守护进程，也是TongLinkQ的系统核心，主要负责数据的收发、控制端对端消息的传输以及监控网络的运行状况。

TongLinkQ的连接

常连接：正常关闭或者发生故障时才关闭的连接，连接断开后会自动连接。

路由：不相邻节点间的通讯。不相邻的两个节点和第三个中间节点组成的通信传输路径称为通信路由。

路由方式 静态路由：由用户配置到某个子网的所有数据经由某个节点转发。匹配规则支持*和？，*代表：后续字符不进行比较，？代表：当前字符不进行比较。使用静态路由方式要注意避免路由的死循环。

消息管理

消息定义：在分布式应用中，不同的应用进程之间传递、交换的信息。消息由消息内容和接收方名单组成。

消息内容及格式由消息的提供者和接收方协商决定。形式上表现为一个数据包或者一个文件。

消息的名称由用户指定，最大长度为48k；消息标识指消息发送方核心产生消息的时间和ID即SRC+MSGID，消息的全局唯一标识。

消息的类型分为数据报消息（BUF_MSG）、文件消息(FILE_MSG)和事件消息(EVENT_MSG)

数据报消息（BUF_MSG）:用户API通过内存BUFF发送和接收消息，发送和接收BUF是两个独立的内存空间，由用户定义内存大小，用户必须定义足够大的内存空间来存储接收和发送的消息 ，空间不够会导致发送和接收消息失败，数据报消息本身没有长度限制，实际受TongLinkQ的可用BUFF数限制。

文件消息(FILE_MSG)：用户通过文件进行消息发送和接收，文件固定的保存在FILESDIR目录下，文件名可包含目录、路径，可带空格，不能用“..”，要保证文件名的唯一性，如果文件名或者路径中带有空格，在发送时需要用“”引起，发送消息识别出文件重复则发送失败，接收方收到重复文件的REQ则需要给发送方回复一个错误信息，停止消息传输；可指定文件发送后是否删除。

事件消息(EVENT_MSG)：系统事件产生的消息。事件存放在事件队列中（包括专门的事件队列EVENT和普通的接收队列），事件分为两类定义的事件和订阅的事件，定义的事件产生的消息存放在专门的事件队列EVENT中，而订阅的事件产生的消息可存放在任意一个可靠的接收队列中。

消息的生命周期

消息的生命周期是消息的所属属性之一，它用来控制消息从开始发送到最终被用户接收所允许的最长时间。消息的生命周期就是消息的存活时间。超过生命周期的消息，系统会自动丢弃。核心通过生命周期这一机制有效的清理一些过期的消息，释放占用的核心资源，保证整个系统的效率。消息生命周期的单位是秒，由用户确定，消息的可靠传输是局限在消息的生命周期内的。

生命周期的设定

发送方生命周期的计算：从提交到核心开始计算，如果有事务，从事务提交开始计算目前生命周期是每三秒减一次，接收方不计算请求包发送所消耗的时间，未和发送方完全同步。

发送方消息生命周期超时：

1 消息未发送完成，则消息结果为发送失败；如果应用订阅消息结果，则产生消息的消息结果，写事件队列。

2 若消息发送完成，则继续等待一个块超时时间，用于等待消息结果返回，若继续等待超时，则消息结果为等待处理结果超时，等待处理结果超时不等于接收方处理消息肯定失败。如果应用订阅消息结果，则产生消息的消息结果，写入事件队列。 3 若应用需要确切结果，可以通过查询日志或者应用层查询来获取消息结果。

接收方的生命周期：接收方接收到消息请求时，其开始的剩余生命周期时间减去在发送队列里等待的时间，但忽略报头传递时间。

注意：如果有未完成的消息（正在发送或者正在接收），不能修改机器时间，因为系统恢复时，会根据消息的创建时间和当前的时间去重新计算消息的剩余周期。

消息的加密和压缩

TongLinkQ提供对消息的加密和压缩的功能。用户可以选择自动加密和压缩。系统会先进行压缩，然后加密。

消息发送方式：

1 API不等待核心应答后返回和API等待核心应答后返回。

API不等待核心应答后返回：发送方API处理完消息后立即返回，不再等待任何应答。这种方式是可以较快的连续的发送消息，因而核心无法即时处理消息，要求有比较大的发送BUF空间，因为不等待应答，核心有可能未收到消息，故不能保证信息的可靠性，并且不产生消息结果。

这种方式只能在独立的发送语句中使用，不支持发送事务过程中的发送语句操作。不支持log_on方式，不支持事务，不支持事件。

API等待核心应答后返回：发送方核心将消息写入发送方队列返回结果，表明TongLinkQ核心已经成功的记录了该消息，API接收到核心的应答后返回。使用这种方法需要定义API等待应答的时间，该时间不能超过消息的生命周期，API超时返回，不能保证TongLinkQ处理消息失败，若需要保证绝对的可靠，需要使用发送过程事务。可用于独立发送和事务发送。

消息的可靠性：用于核心收到消息后的管理。不负责API与核心间通讯过程中消息的可靠性管理。TongLinkQ系统提供两种消息：可靠消息和非可靠消息。

非可靠消息（LOG_OFF）的消息数据保存在内存里，TongLinkQ运行时支持网络故障断点续传。TongLinkQ重新启动后，消息丢失，这种方式应用在需要较高传输效率的系统。

可靠消息（LOG_ON）的消息保存在数据硬盘上，TongLinkQ运行时支持网络故障断点续传，TongLinkQ重新启动后，根据接收方接收消息的大小进行恢复，实现断点续传，但可能丢失的部分数据会重复传送（有可能这部分数据接收成功，也有可能接收失败），可能丢失的数据大小依赖于TCP的BUF大小和策略。

消息的优先级：TongLinkQ系统为了处理消息的优先层次提供了消息优先级的功能，可以对不同级别的消息进行相应的处理。

每个发送队列可以包含多个优先级，优先级可以定义，最多为10级。可以定义每个优先级所允许发送的块数；TongLinkQ按照块数比例发送各优先级中的消息，高优先级的消息有更多的发送机会，同一优先级中的消息顺序发送，即先到先发。

在发送队列中，1有转发优先权，用于设置需要转发的数据块数，可以定义可获取发送时间（机会）的比率；2 有系统优先权，用于存放系统消息，具有最高的优先级，系统优先级里的消息发送完毕之后才能发送其他优先级中的消息，不支持独占优先级（强占所有时间）和等待优先级（无其他消息发送时才发送）。