logo

 
您当前的位置:首页»范文大全»毕业论文»毕业设计»基于cnaps的流水号管理方法

基于cnaps的流水号管理方法

摘 要:中国国家现代化支付交易清算系统(china national automation payment system),简称cnaps,是中国人民银行在世界银行贷款支持下正在建设中的中央银行支付系统,该系统的主要功能是对各商业银行的资金进行最终的清算。文章分析了目前cnaps系统可靠性,响应时间等方面的一些不完善之处,介绍了改善系统可靠性,缩短系统响应时间的方法,即流水号管理。关键词:cnaps sb分行系统 资金清算 流水号 套接口商业银行(special bank)之间的资金收、付交易,必须经过政府授权的中央银行进行资金清算,以发挥中央银行的宏观调控功能,从而稳定货币、稳定市场。cnaps系统即是由各级中央银行组成, 因此sb分行系统必须和cnaps系统通信,通过cnaps系统完成资金的最终清算。cnaps系统的可靠、有效运行,将关系到企业、个人的资金是否实现有效、及时、可靠的转移,对维护和健全银行体系,完善金融市场是至关重要的。cnaps系统中数据的传送是全双工的。一方面是cnaps向sb发送信息或文件;另一方面sb也向cnaps发送信息或文件。以下着重分析cnaps向sb发送信息或文件时的情况,sb向cnaps发送信息或文件时的情况与此类似。1 目前cnaps系统的一些不完善之处目前在cnaps向sb发送信息或文件的路径上存在以下不足之处:接收端不能得到独立的信息或文件;文件请求响应时间过长;传输层能提供的可靠性有限。1) 不能得到独立的信息和文件两个应用程序通过tcp连接交换8bit字节构成的字节流。tcp不在字节流中插入记录标识符。我们将这称为字节流服务(byte stream service)。如果一方的应用程序先传10字节,又传20字节,再传50字节,连接的另一方将无法了解发方每次发送了多少字节。收方可以分4次接收这80个字节,每次接收20个字节。一端将字节流放到tcp连接上,同样的字节流将出现在tcp连接的另一端。tcp对字节流的内容不作任何解释。对字节流的解释由tcp连接双方的应用层解释。当cnaps向sb发送信息或文件时,sb得到的只是无记录标识的字节流,而无法还原出独立的信息或文件。2)文件请求响应时间过长在cnaps系统中,sb作为客户机,cnaps作为服务器运行,客户是指主动发起通信请求的应用程序,而服务器是被动等待接收通信请求的应用程序。所以在cnaps向sb发送信息或文件的路径上,cnaps不会主动向sb发送信息或文件,它必须首先收到sb的请求。在cnaps向sb发送信息或文件的路径上,sb向cnaps发出信息或文件请求的同时启动一个定时器,当定时器超时(仍未接收到正确的信息或文件)sb则认为这个请求丢失或损伤因而进行重传。当cnaps与sb传送的数据单元是文件时,由于文件数据量很大,正常情况下都要经过很长的时延才能从cnaps端全部传送到sb端, 因此定时器的时间应设置为比较大的值,sb往往要等待很长的时间才能判断是否重发请求,sb的响应时间很长。特别是当cnaps发送的文件有一小部分出错,sb端tcp检查到效验和出错时就会抛弃整个文件,接着sb定时器超时,sb重发请求,cnaps再次重发整个文件,sb从发出第一次请求开始,需要经历很长的时间才能接收到完全正确的文件。3)传输层能提供的可靠性是有限的cnaps系统的传输层采用的是tcp传输控制协议,理论上tcp协议是可靠的,然而实际的传输服务并非毫无错误,但在不可靠的网络之上提供可靠的服务正是传输层要实现的目标。传输层是增强网络层提供的服务质量,它必须弥补应用层用户要求与网络层所提供的服务之间的差别。用户在建立连接时对各种服务参数(如残余误码率)指定希望的、可接受的最低限度的值,传输层根据网络服务的种类或它能够获得的服务来检查这些参数,决定能否提供所要求的服务。当传输层发现服务质量参数的某些值是无法到达的,传输层甚至不去与目的机器连接,便直接通知应用层连接请求失败。因此传输层能提供的可靠性是有限的。2 cnaps系统性能改善方法--流水号管理改进了的cnaps系统在cnaps发送信息或文件的路径上都增加了流水号管理的通信处理机制,进一步增强cnaps系统可靠性,并缩短了文件请求/发送的响应时间。一、 对接收方信息或文件不能独立和文件请求响应时间过长的解决在cnaps发送信息或文件的路径上,发送数据在cnaps端,为保证sb端接收到独立的信息或文件,通信上采用sb请求一次,cnaps发送一次的办法。cnaps给它生成的每个信息分配一个流水号,以标识该信息在cnaps数据流中的位置。通信上sb请求一个流水号,cnaps才发送流水号为对应值的信息。这样各个信息就能分开。在cnaps向sb发送信息路径上流水号的处理过程可分成三步:1)当系统开始,链路建立后sb向cnaps发初始化流水号请求,随后cnaps向sb发送初始化流水号回答,把sb的流水号初始化为0。不是系统开始,如出现故障链路断开再次建立,链路建立后sb会向cnaps发证实流水号请求,如cnaps判断sb的流水正确,cnaps会发出证实流水号回答。2)接着sb开始不断地向cnaps发送信息请求并从cnaps接收信息,直到接收到cnaps端无信息发送电文为止。当sb端接收到cnaps的无信息发送电文,隔一段时间,sb又会向cnaps发送信息请求。3)当一天结束时,sb端会向cnaps发送一个结束流水号请求,当sb接收到cnaps的结束流水号回答后,sb断开链路。证实流水号请求和证实流水号回答(或初始化流水号请求和初始化流水号回答)这两个步骤称为流水号同步,通过流水号同步,sb可以知道已经接收到cnaps发送数据流的什么位置。(这类似于tcp的三步握手)。在tcp的三步握手协议中,因为数据传输是双向的,所以要完成客户和服务器的同步需要三个步骤。在cnaps系统中,cnaps发送信息路径上数据是由cnaps向sb端单向传输,因此在该路径上cnaps和sb的流水号同步只需两个步骤。下面是日初系统开始时, cnaps向sb发送信息路径上,cnaps端有2个未发送信息时流水号的处理过程(文件接收路径上流水号的处理过程与此类似):cnaps(日初流水号初始化为0) sb(流水号为上日终止时的值50)图2-1 没有电文丢失、重复等错误的理想情况(未到一天结束时)图2-1直线两侧数值是cnaps端和sb端的流水号,斜线上表示是sb和cnaps之间的传送电文。cnaps端流水号是指cnaps已发送且被sb正确接收到的信息的个数(如cnaps端流水号为3,表示cnaps已发送出去3个信息且这时sb接收到的信息个数也是3)。sb流水号是指sb已正确接收到信息的个数。cnaps流水号的更新是在cnaps接收到sb请求下一个流水号时,这时cnaps就知道上一个流水号已被sb正确接收到了。sb端流水号的更新是当sb正确接收到了信息。规定sb必须正确接收到一个流水号才能请求下一个流水号。 斜线上sb信息请求报文中请求的流水号为sb 端的流水号+1,即sb希望接收到的下一个cnaps信息的流水号。2) 在cnaps向sb发送文件的路径上流水号处理过程与cnaps向sb发送信息路径上流水号处理类似。把cnaps生成的文件分成若干分块,给予每个分块一个流水号,以标志该文件分块在cnaps数据流中的位置(分块大小的指标是保证sb文件分块请求的响应时间可以接受)。通信上sb请求一个流水号,cnaps才发送流水号为对应值的文件分块。当文件传输过程中出现错误时,sb能及时发现,只需要cnaps重传某个文件分块,而不用整个文件重新传送。由于文件分块的数据量不大而且sb能及时处理错误,因此sb正确接收到整个文件的响应时间比不采用流水号管理时的响应时间大大缩短了。当一个文件接收完毕,sb才请求下一个文件,这样每个文件也能独立开来。流水号处理过程与图2-1类似。二、对传输层只能提供有限可靠性的解决流水号管理中采用了类似于传输层tcp协议的一些机制,相当于在应用层进一步增强传输层可靠性。1) 超时重传机制tcp协议中为了解决分组的丢失,采用的是超时重传机制。客户发出连接请求的同时启动一个定时器,不管请求或者响应丢失,定时器总会超时溢出。一旦定时器超时,客户再次发起连接请求,并重新启动定时器。直到成功建立连接,或当重传次数到达一定限度时,认为连接不可建立而放弃。在cnaps向sb发送信息或文件路径上的流水号管理采用了类似tcp的超时重传机制,sb发出信息或文件分块请求的同时启动一个定时器。当cnaps返回的信息或文件分块因线路噪声损坏,sb方就会检测到出错,从而丢弃它们。在sb定时器时间到达时仍未收到正确的信息或文件分块,sb就会断开连接。2) 序号机制tcp协议中通过给数据流中每个八位组赋予序号并要求接收方记住所收八位组的序号来检测重复现象。为了避免迟到的确认和重复确认带来的混乱,tcp的'带重传的肯定确认'协议在确认信息中携带一个序号,这样接收方就能正确地把分组与确认关联起来。在cnaps向sb发送信息或文件路径上对信息或文件分块进行编号,这种编号称为流水号,每个待发送数据都对应一个流水号的机制使得接收端能够辨别接收数据是否重复。4 结论cnaps系统在我国金融界举足轻重的地位决定了必须从多方面保证它的可靠性,否则一个失误可能会导致上百亿元的资金流失。在cnaps系统中运用流水号的管理方法是非常必要的,它可以进一步增强系统可靠性,缩短系统的响应时间。[参考文献][1] 周明天 汪文勇,《tcp/ip网络原理与技术》,清华大学出版社,1993年12月[2] 中国人民银行支付与科技司,《中国国家现代化支付系统》,中国金融出版社,1995年8月