基于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协议是可靠的，然而实际的传输服务并非毫无错误，但在不可靠的网络之上提供可靠的服务正是传输层要实现的目标。
《基于CNAPS的流水号管理方法(第2页)》
★读了本文的人也读了：