FNP通信通道表建立算法设计与实现

(整期优先)网络出版时间:2022-09-22
/ 3

FNP通信通道表建立算法设计与实现

1朱烨中,2龚伟,2葛纪荣

上海备特楼宇科技有限公司 上海市 200000

上海地铁第一运营有限公司 上海市 200000

Design and Implementation of FNP Communication Channel Table Establishment Algorithm

摘要:FNP是消防消防报警系统通用网络站点间通信协议,使用通信通道表进行站点间通信。本文介绍了FNP网络中通信通道表的建立维护,以及各站点的副本同步算法,在此基础上,给出了站点间通信的程序伪码,用此方式能够实现FNP网络中的网络通信。

关键词:FNP;通信通道表;数据同步

FNP(Fas alarm Network communication Protocol)是基于城市轨道交通广泛采用的高速光纤骨干网络中的通信协议,用于城市轨道交通消防报警系统通用网络站点间通信。

在FNP中,使用TCP/IP socket UDP方式通信,在网站点的网络IP地址收集在通信通道表(Channel Table)中,站点间通信首先通过通道信息表获取对方的IP地址,再将需要传送的数据组装成FNP报文,递交给TCP/IP协议层,以UDP方式发送到对方,如图1所示。

 

图1 FNP站点间通信

所以,通信通道表对于使用FNP协议通信来说成为重要,ChannelTab由主控中心站点负责维护,本文就从通道表的建立、更新和使用等方面设计通信通道表相关算法设计。

1 通道表

在城市轨道交通消防报警通用网络系统处于运行时,维护一份最新的ChannelTab,并且为每一个在线站点分发一个ChannelTab副本。ChannelTab中的信息分主要为三类:在线监视类;通信类;站点基本信息。如表1所示。

表1 ChannelTab主要信息

监视类

time

计时时钟。通道对应的站点在线时时钟计数,并与计算机系统保持一致;离线时停止计数。

online

0-离线, 1-在线

通信类

port

UDP端口地址

addr

IPv4地址

WaitingAckPool

等待应答缓冲池。暂存已发送未收到接收确认的报文,当超时没有收到对方接收确认,从缓冲池中取出报文重发,当重发次数超过规定次数时,放弃重发,并将报文移出缓冲池。

站点基

本信息

id

站点ID(站点唯一编码)

level

中心站等级。0-普通站点, 1~255-中心站点,数字越大等级越高。

name

站点名字。

网络中的ChannelTab由主控中心站点维护,并将副本实时地下发到网络中实时在线的各站点。各站点每隔一段时间将ChannelTab表保存在本地。

2 通道表建立算法

ChannelTab由主控中心站点维护,其时序流程如图2所示。

 

图2 通信通道分配与通道表信息更新

设有一站点i,完成一次站点i的ChannelTab信息更新过程:网站i点将自身信息诸如,占用的通道号cn、站点IP地址、站点ID、站名…,定期提交给主控中心站;主控中心收到后,检查ChannelTab,若cn未分配,或cn已分配给其他站点,则为此站点重新分配一个cn;ChannelTab[cn].time计时,与系统时钟一致;返回最新的cn给站点i。

随着这一过程循环往复,周而复始地执行,主控中心站收集到网络中所有站的信息,从而使ChannelTab中存放的数据始终是最新的数据。

2.1 站点上线

最开始时ChannelTab为空,每当一个新站点,比如说站点Si进入网络时,Si向控制中心站发自己的相关信息,由主控中心站将Si存放ChannelTab中。

Si相关信息通过配置文件提供,存储在本地,诸多信息中比较关键的有两项:通信通道号cn和站点ID。cn表示到目前为止Si的通道号,cn可能仅仅是Si从本地配置文件设定的,也可能是主控站点分配的,所以有可能ChannelTab中并不存在cn通道,或cn与其他站点的通道号冲突,但是在ChannelTab中cn是否存在,或是否冲突,Si本身不能判断,必须由主控站点通过比对ChannelTab内容,才能断定。

如果cn在ChannelTab中不存在,或与其他站点的cn有冲突,则由主控站点重新分配一个,以取代先前的cn。由此可见,每个站点的cn可能随着网络的实际情况而发改变,这不利于使用cn来通信,为避免这种情况,使用站点ID,即每个网络中的站点必须要赋有一个唯一的站点编号,或站点ID,通信时,可能先通过站点ID先确定当前的cn,再根据cn在ChannelTab中取通信的IP地址,从而避免由于cn的改变给通信带来的不便。

接着主控站点用收到Si发送过来的最新信息,刷新ChannelTab中对应项的信息,主要是IP地址和时钟计时。除了主要信息,还有其他次要信息,但和通信无关,这里就不展开细述。

通过这种网络站点定期向主控中心发送信息,或者说主控中心站点定期收到来自网络站点信息这种机制,FNP协议的实现程序,可以将新上线站点加入到ChannelTab,并且始终保持ChannelTab中的信息处于最新状态。

2.2站点离线

对于正常下线,站点可以通过向主控中心发送报文,主动报告自己下线动作,主控中心收到报文后,在ChannelTab中标识该站点处于离线状态,并且其计时时钟停止计时。

对于非正常下线的,站点不能主动报告自身离线,针对这种情况,可以在主控中心站点设置一个监视器,定时检查ChannelTab,当某一通道中的计时时钟停止计时,超过规定时间(比如说30秒)即判定为非正常离线,并将其对应的通道设置为离线状态,如图3所示。

 

图3 通信cn的离线监视

图3仅列示是单个通道的离线监视时序流程框图,实际实现时,使用一个循环,遍历ChannelTab中的每一个通道,从而对所有通道实行监视。

处于离线状态的通道仍然保留在ChannelTab中,但是当一个站点超过一定期限(比如30天)没有上线,则监视程序认为该站点永久离线,并将该站点相对应的通道从ChannelTab中移出。

综上所述,通过采用主控站点定时收集网络上站点信息的机制,及采用定时监视各通道的离线的机制,维护ChannelTab,使ChannelTab能够记录各通道在线的实时状态。

3 通道表副本同步

使用FNP协议通信,网站间依据ChannelTab副本通信,所以如何保持各站点的ChannelTab副体与主控中心站点的ChannelTab正本保持实时同步尤为关键。

主控中心站点采用定时同步机制,进行各站点间通信通道表的同步操作,如图4所示。从ChannelTab第1个通道Ch1开始,即i=1,每一个定时到来,主控站点从ChannelTab中取若干(n)条通道信息,即Chi, Chi+1, …, Chi+n;i'=i+n;采用组播(广播)方式发送到各站点,更新其本地的ChannelTab副本,直到ChannelTab同步完毕。如此反复,循环执行这一过程,实现ChannelTab的正本与副本的实时同步。

对于一个正在运行的网络来说,除了最开始网络启动阶段,会存在ChannelTab副本信息稍有延时外,其他时间分布在网络中的ChannelTab正本和副本信息完全一致。

 

图4 ChannelTab的同步操作

4 基于通道表站点间通信

对于网络中有主控站点存在的情况,在主控站点的同步下,各站点在本地保存的ChannelTab内容完全一致,就如同整个网络中只存在一个ChannelTab,能及时反映出各站点当前的网络通信的IP地址等,所以,站点间通信完全可以依据同一的ChannelTab进行。

例如,站点A所在的通信通道为Cha,站点B所在的通道为Chb,从A向B发送数据的程序伪码为:

int SendData(unsigned int ch_b, char *data, int n)

{

to.sin_addr.s_addr = ChannelTab[ch_b].addr;

to.sin_port = ChannelTab[ch_b].port;

msg = MakeMsg(data, n);//数据组装成PNP报文

sendto(sock, &msg, len, to, sizeof(to));//将FNP包递交给

return waitingACK(&ChannelTab[ch_b]);//等待站点B的收到确认。

}

由于主控站点处理通道号的冲突机制,站点的所对应的通信通道号可能会改变,为了应对这种情况,可以使用站点ID来确认发送数据的目的站点。

例如,站点A的ID为IDa,站点B的ID为IDb,从A向B发送数据的程序伪码为:

int SendDataByID(unsigned int id_b, void *data, int n)

{

for(k=1; k<=last_cn; k++)

if (ChannelTab[k].id==id_b)break;

if(k>last_cn)return -3;

ch_b = k;

return SendData(ch_b, data, n);

}

对于网络中无主控中心站点存在的情况下,比如主控中心站在T时刻离线,那么网络中的各站点的ChannelTab信息将停止在T时刻,而不再更新。虽然ChannelTab信息不更新,但是它存的信息仍然可用,此时仍然可用前面两种方式与网络中各站点间进行通信。

当某站点离线,由于不网络上没有主控中心站点存在,故离线状态不能及时同步到各站点的ChannelTab,此时虽然仍然可以使用SendData及SendDataByID进行通信,但由于接收站点离线,发送端收不到接收确认,而得到一个发送超时的返回结果。所以,这种情况下,可以通过发送超时来判断接收方是否在线。

5 结论

在FNP中,由主控中心来维护通信通道表ChannelTab,一方面主控站点实时收集各站点的信息,实时更新ChannelTab正本,另一方面,用组播(广播)方式,将ChannelTab正本实时同步各站点本地的ChannelTab副本,使用网络中的ChannelTab正本和副本内容一致。

通过站点本地的ChannelTab,不论网络中的主控站点在线,还是离线,各站点均可依据本地ChannelTab通信,在主控站点离线的情况下,可以通过发送超时来判断接收方是否离线。

参考文献

[1] 钟辉,臧晗,董洁,等. TCP/IP网络编程原理与技术[M].北京:清华大学出版社, 2019.

[2] 黄继海,石彦华.linux 环境下C程序设计[M].北京:人民邮电出版社,2021.

[3] 成洁,卢紫毅.Linux窗口程序设计[M].北京:清华大学出版社,2008.

[4] 杜永文,李金玉,兰丽.linux 开发及使用详解. 兰州:兰州大学出版社,2015.

[5] [美]Maksimchuk,R.A.,[美]Naiburg,E.J., 李虎,译. UML初学者指南. 北京:人民邮电出版社, 2005.

[6] [美]Michael Blaha,James Rumbaugh. UML面向对象建模与设计(第2版). 北京:人民邮电出版社,2011.

[7]杨春丽.吴绿野.城市综合体火灾自动报警系统设计[J].建筑电气,2015,(1):28-31.