CN101009535A

CN101009535A - 基于滑动窗口的soap消息传输方法

Info

Publication number: CN101009535A
Application number: CN 200710063112
Authority: CN
Inventors: 怀进鹏; 刘力; 刘旭东; 林学练; 李静; 崔毅
Original assignee: Beihang University
Current assignee: Beihang University
Priority date: 2007-01-26
Filing date: 2007-01-26
Publication date: 2007-08-01
Anticipated expiration: 2027-01-26
Also published as: CN101009535B

Abstract

本发明公开了一种基于滑动窗口的SOAP消息传输方法，它是将SOAP消息待传输的数据切片，将分割后得到的数据切片作为附件封装到SOAP消息中，再将含有数据切片附件的SOAP消息装入滑动窗口中，使用滑动窗口来控制和提升SOAP消息的传输速度。为了保证SOAP消息传输的可靠性，在SOAP消息级滑动窗口具体设计和实现时，对数据消息丢失、响应消息丢失、接收方收到重复数据消息以及接收方等待数据超时等情况进行了有效的分析和处理，并应用了一种应用层的拥塞控制机制，以保证SOAP消息传输的畅通。本发明的特点：充分利用了网络带宽，提高了SOAP消息传输效率，并保证消息传输的可靠性。

Description

基于滑动窗口的SOAP消息传输方法

技术领域

本发明涉及一种SOAP消息传输方法，具体地说，本发明涉及一种基于滑动窗口的SOAP消息传输方法。

背景技术

基于Web服务的分布式计算模式已经成为网络发展潮流。Web服务使用SOAP作为其基本的通信协议。SOAP(Simple Object Access Protocal)是一种轻量级协议，它基于XML技术定义了一种可扩展的消息处理框架，已成为开放网络环境下信息交换的一种事实标准。

尽管SOAP提供了强大的互操作性，但是其自身的特点决定了其传输效率较低。原因是：一般情况下，将数据封装到SOAP消息后，将变为原来大小的4-10倍，此外，其他格式数据和SOAP消息相互转换时，在编码转换以及报文构造和解析上需要消耗大量时间，加上网络传输的时间消耗，导致一次SOAP消息传输从发送到接收到响应需要较长时间。对于数据传输效率要求较高或者大数据量传输的应用，SOAP不能很好的满足实际需要。

针对SOAP消息传输效率低的问题，目前已经有不少解决方案，如：

方案1：通过改进消息传输协议来提高传输效率，例如使用TCP、UDP协议代替当前广泛使用的HTTP协议来传输SOAP消息，采用HTTP1.1传输协议代替HTTP1.0传输协议等。

方案2：减少SOAP消息构造和解析时间，例如使用SAX代替DOM，使用效率较高的XML拉式解析技术取代XML推式解析技术。

方案3：根据不同的应用场合，采用适合的SOAP消息编码规则。目前常用的SOAP消息编码方式主要有SOAP RPC Encoding，RPC-LiteralEncoding以及Document-Style Encoding方式。

方案4：改进SOAP附件编码方式，例如采用最新的SOAP消息附件规范XOP、MTOM来封装SOAP消息附件等。

虽然，人们采用上述方案在一定程度上提高了SOAP消息的传输效率，但是，其效果并不明显，仍然存在SOAP消息传输效率低的问题。

发明内容

鉴于上述原因，为了提高SOAP消息传输效率，本发明的主要目的是提供一种基于滑动窗口的SOAP消息传输方法(SOAP Level Sliding Window，简称SOAPSW)，该方法将SOAP消息待传输的数据切片化，同时将滑动窗口机制引入到SOAP消息传输中来，使用滑动窗口来控制和提升SOAP消息的传输速度，并保证消息传输的可靠性，同时提出了相应的拥塞控制方法。

为实现上述目的，本发明采用以下技术方案：一种基于滑动窗口的SOAP消息传输方法，其特征在于：将SOAP消息待传输的数据切片，将分割后得到的数据切片作为附件封装到SOAP消息中，再将包含有数据切片附件的SOAP消息装入滑动窗口中，使用滑动窗口传输包含有数据切片的SOAP消息。

本发明基于滑动窗口的SOAP消息传输方法主要包括以下步骤：

A、发送方和接收方进行三次握手建立传输关系，该方式可以采用约定的传输协议或者端口实现；在三次握手中，需要确定如下内容：SOAP附件封装规范、传输协议、滑动窗口大小、数据切片大小、超时时间间隔、超时重传次数上限、一个SOAP消息中数据切片个数等信息；

B、根据三次握手建立的约定，分别对发送方和接收方进行初始化，包括初始化滑动窗口，启动各自的定时器等；

C、发送方从文件系统或者网络等其他数据源中按照约定的数据切片大小读取数据，将数据切片封装成SOAP滑动窗口数据消息，并放入滑动窗口中进行发送，发送结束之后等待接收方的响应消息；

D、接收方接收SOAP滑动窗口数据消息，解析该SOAP消息，并根据解析结果，选择是将数据放入滑动窗口中，还是将其丢弃；对于放入滑动窗口中的数据，再判断数据是否接收完毕，滑动窗口是否滑动，并向发送方发送SOAP滑动窗口响应消息；

E、发送方收到SOAP滑动窗口响应消息后，解析该SOAP消息，并根据解析结果，判断数据是否发送完毕，如果没有发送完毕，判断是重发数据消息，还是将其滑动窗口进行滑动以读入后续数据并发送；

F、发送方、接收方不断重复上述第D步～第E步直到数据发送完毕。

附图说明

图1为本发明将SOAP消息附件切片传输的示例图；

图2为本发明发送窗口变化示意图；

图3为本发明接收窗口变化示意图；

图4为一个具体的发送方发出的SOAP数据消息内容示例；

图5为一个具体的接收方发出的SOAP响应消息内容示例；

图6为本发明发送方基于滑动窗口传输SOAP消息的流程图；

图7为本发明接收方基于滑动窗口传输SOAP消息的流程图；

图8为SOAP消息传输过程中协议层次结构图；

图9为SOAP消息滑动窗口具体设计过程中需要考虑的四种情况；

图10为本发明拥塞控制方法流程图；

图11为采用本发明公开的方法，SOAP消息传输时间与窗口大小的关系图；

图12为采用本发明公开的方法，SOAP消息传输时间与数据切片长度的关系图。

具体实施方式

正如背景技术部分所述，目前，SOAP消息的大小为其封装数据(即SOAP消息要传输的数据)大小的4-10倍；同时SOAP消息在编码转换以及报文构造和解析上需要消耗大量时间，加上网络传输的时间消耗，SOAP消息传输效率低。

故，为了提高SOAP消息传输效率，本发明将SOAP消息待传输的数据切片，同时引入滑动窗口的概念，使用滑动窗口来控制和提升SOAP消息的传输速度，从而达到充分利用网络带宽，提高SOAP消息传输效率的目的。

下面结合附图详细说明本发明。

1.数据切片

为了提高SOAP消息的传输效率，对于SOAP消息要传输的数据，本发明采用数据切片的方式，将大数据文件基于MIME协议分成多个切片；分割后的数据切片作为SOAP消息附件进行传输，发送方可以向数据接收方每次发送包含有一个数据切片的SOAP消息附件，也可以发送包含多个数据切片的SOAP消息附件。通过将一个包含大附件的完整的SOAP消息数据分成多次同时传输，提高了SOAP消息的传输效率。

由于SOAP消息附件中封装的不是一个完整的数据，而是一个或多个数据切片，所以，在SOAP消息主体中，至少需要包含以下信息：SOAP消息编号(SOAPID)，待发送的数据编号(DataNumber)，切片编号(SliceNumber)，是否是最后一个数据(isLastData)，是否是最后一个切片(isLastSlice)。SOAPID用来唯一确定数据切片所属的SOAP消息编号，DataNumber用来表示该数据切片所在的数据编号，即当前传输的是第几个数据，SliceNumber是数据切片编号，表示当前传输的是第几个数据的第几个数据切片，isLastData表示是否是最后一个数据，isLastSlice表示是否是当前正在传输的数据的最后一个数据切片。一次传输多个附件或者大附件的SOAP消息可以分解成多个这种形式的小型SOAP消息。

图1是一个将SOAP消息附件切片传输的示例。在该示例中，SOAP消息被从A点发送至B点，SOAP消息编号(SOAPID)为598，需要传输两个数据，数据编号(DataNumber)为0、1，第一个数据被分为4个数据切片，切片编号(SliceNumber)为0、1、2、3，第二个数据被分为2个数据切片，切片编号为0、1。即原始的包含有两个数据的SOAP消息附件被分解成六个包含有数据切片的SOAP消息附件。

将一个包含有较大数据附件的SOAP消息分成多个包含有数据切片的小的SOAP消息，避免了一次将整个数据读入到内存中，便于对数据附件进行加密和解密，同时，还支持大数据SOAP消息附件的传输，以及大小难以确定和大小动态变化的附件。

2、利用滑动窗口进行SOAP消息传输

为了充分利用网络带宽，提高SOAP消息传输效率，本发明在发送方和接收方分别用一个滑动窗口来存储待传输的或者接收到的包含有数据切片的SOAP消息。

窗口用来存储数据传输过程中的数据，当数据需要被更新时，窗口将滑动。滑动窗口协议的基本原理就是在任意时刻，发送方都维持一组连续的允许发送的数据信息，称为发送窗口；同时，接收方也维持一组连续的允许接收的数据信息，称为接收窗口。发送窗口和接收窗口的大小可以不同，上下界不一定要一样。不同的滑动窗口协议窗口大小一般不同。

如图2所示，发送方窗口内的数据只有发送出去并且被确认之后，窗口才能滑动，读入新的数据。如图3所示，接收方窗口内的数据只有接收成功并被读出之后，窗口才能滑动。

在基于滑动窗口的SOAP消息传输方法中，每个窗口中存放的是一个SOAP滑动窗口数据消息。

对于选择重传协议方式的滑动窗口，当接收方发现某数据消息出错后，其后继续送来的正确的数据虽然不能立即递交给接收方的高层，但接收方仍可收下，存放在接收方滑动窗口中，同时要求发送方重新传送出错的那一个数据。一旦收到重新传来的数据后，就可以和原已存于缓冲区中的其余数据一并按正确的顺序递交高层。

3.SOAP消息结构定义

滑动窗口中的SOAP消息分为两种：SOAP滑动窗口数据消息和SOAP滑动窗口响应消息，这两种消息均为SOAP消息。

SOAP滑动窗口数据消息由发送方发出，每个数据消息中包含一个或多个数据切片的数据，切片大小可以任意也可以固定，按照约定的SOAP消息附件规范封装入SOAP消息中。在SOAP消息主体中需要指明该数据的基本信息，如：SOAP消息编号(SOAPID)、待发送的数据编号(DataNumber)、切片编号(SliceNumber)、数据切片个数、每个数据切片的大小、所采用的SOAP附件封装规范、以及是否是当前正在传输的数据的最后一个数据切片(isLastSlice)和是否是最后一个数据(isLastData)。如果需要加密，在SOAP消息主体中还要有安全信息等。图4给出了一个具体的发送方发出的数据消息内容示例，该例采用的是基于XOP的SOAP消息封装规范，Data标签中使用XOP指向SOAP数据切片所在的MIME附件。

SOAP滑动窗口响应消息由接收方发出，是对发送方发出的数据消息的确认。响应消息的SOAP消息主体中包含如下信息：SOAP消息编号(SOAPID)，已确认的数据编号(ACKDataNumber)、已确认的数据切片编号(ACKSliceNumber)、是否是当前正在传输的数据的最后一个数据切片(isLastSlice)、是否是最后一个数据(isLastData)、响应消息类型(ACKType)以及具体响应信息(ResponseInfo)。ACKDataNumber和ACKSliceNumber标签联合表示对第几个数据的第几个切片的确认。图5给出了一个具体的接收方发出的响应消息内容示例。

4、本发明基于滑动窗口的SOAP消息传输方法：

在建立了数据切片、滑动窗口的概念后，下面详细描述本发明基于滑动窗口的SOAP消息传输方法，其主要步骤包括：

A、发送方和接收方进行三次握手建立传输关系，该方式可以采用事先约定的传输协议和端口来实现。在三次握手中，需要确定如下内容：SOAP附件封装规范、传输协议、滑动窗口大小、数据切片大小、超时时间间隔、超时重传次数上限、一个SOAP消息中数据切片个数等信息；

图6和图7为本发明基于滑动窗口的SOAP消息传输具体流程图，图6为发送方基于滑动窗口的SOAP消息传输流程图，图7为接收方基于滑动窗口的SOAP消息传输流程图。

下面结合图6详细描述发送方基于滑动窗口的SOAP消息传输过程，如图所示；

A、首先，发送方通过三次握手方式与接收方建立连接，三次握手之后，根据约定初始化发送方滑动窗口，启动定时器；

B、发送方从文件系统或者网络等其他数据源中按照约定的数据切片大小，以数据切片为单位读取数据；

C、将数据切片封装至SOAP附件中；将待传输数据基本信息写入SOAP消息主体内容中；生成SOAP滑动窗口数据消息，并将其放入滑动窗口中；

D、判断滑动窗口是否已满？如果没满，则重复执行第B～第D步；如果已满，则执行以下步骤；

E、定位窗口中所有尚未发送以及发送之后等待响应消息超时的数据消息；

F、判断尚未发送的数据消息，其发送次数是否超过上限？如果其发送次数超过上限，则该数据发送失败，结束；如果其发送次数没有超过上限，则执行以下步骤；

G、发送所有尚未发送的滑动窗口数据消息，并将其发送次数加1；

H、等待接收方发送的SOAP滑动窗口响应消息，并计时；

I、判断等待SOAP滑动窗口响应消息的时间是否超时？如果超时，则重新执行第E～第I步；否则，一直等待接收SOAP滑动窗口响应消息；

J、接收SOAP滑动窗口响应消息，并解析SOAP滑动窗口响应消息，获取响应消息；

K、判断数据消息是否已经发送完毕？如果发送完毕，说明数据发送成功并结束；如果没有发送完毕，则发送方滑动窗口滑动；

L、确定后续待读入的数据切片消息，重新执行第B～第K步，直到数据发送完毕，结束。

下面结合图7详细描述接收方基于滑动窗口的SOAP消息传输过程，如图所示；

A、首先，接收方通过三次握手方式与发送方建立连接，并根据三次握手的规定的参数初始化接收方滑动窗口，启动定时器；

B、等待发送方发送的SOAP滑动窗口数据消息；

C、判断等待发送方发送的SOAP滑动窗口数据消息的时间是否超时？

如果超时，则将获取滑动窗口数据消息的等待超时次数加1，并判断超时次数是否超过上限，如果超过上限则说明数据接收失败并结束；如果没有超过上限，则跳转执行第I步；

如果没有超时或没有大于超时等待次数上限就接收到发送方发送的SOAP滑动窗口数据消息，则执行以下步骤；

D、接收发送方发送的SOAP滑动窗口数据消息；

E、验证接收到的数据消息是否正确？如果不正确，则丢弃该错误数据消息，则跳转执行第I步；如果正确，则执行以下步骤；

F、解析接收到的SOAP滑动窗口数据消息，获取数据切片；

G、将数据切片放入接收方接收滑动窗口中；

H、判断是否接收到序号连续的前几个数据？如果是，则将连续的前几个数据切片写入文件系统或其他数据接收目的地；如果不是，则直接执行下一步：

I、接收方基于接收到的SOAP滑动窗口数据消息情况，构造SOAP滑动窗口响应消息；

J、采用具体传输协议发送SOAP滑动窗口响应消息；

K、判断数据是否全部接收完毕？如果数据全部接收完毕，则结束；否则，重新执行第B～第K步直到结束。

SOAP滑动窗口数据消息和SOAP滑动窗口响应消息可以采用各种传输协议作为SOAP消息的承载协议进行传输，并且可以采用常用的SOAP消息规范来对数据进行封装和加密等。图8为协议层次结构图，最上层是SOAP消息滑动窗口(Slide Window)，它表示是以窗口的形式传输SOAP消息，采用将数据切片的方式进行数据传输，并保证消息传输的可靠性，提供拥塞控制机制；中间层是各种SOAP消息的规范，比如SwA、MTOM等，SOAPSW均与其兼容；底层是各种传输协议，例如：TCP、SMTP、HTTP等。

5、保证SOAP消息传输可靠性

为了保证SOAP消息传输的可靠性，在SOAP消息级滑动窗口具体设计和实现时，需要对以下四种情况：数据消息丢失、响应消息丢失、接收方收到重复数据消息以及接收方等待数据超时，进行有效的分析和处理。

如图9(a)所示，发送方发送给接收方的数据消息丢失：发送方等待一定时间之后仍然没有收到响应消息，便重发该数据消息。如图9(b)所示，接收方发给发送方的响应消息丢失：发送方等待一定时间之后仍然没有收到响应消息，也重发超时的数据消息。如图9(c)所示，接收方收到重复数据消息时，接收方将丢弃该重复消息，并重发对最大数据切片的确认。如图9(d)所示，接收方等待数据消息超时，接收方将重发对最大数据切片的确认，然后等待下一个超时时间，如果等待超过最大超时时间，便认为发送方失效。

6.拥塞控制算法

在这种基于滑动窗口的SOAP消息传输过程中，当发送方向网络中注入数据过快时，容易造成网络拥塞。虽然TCP协议具有拥塞控制机制，但其属于传输层协议，用其来控制应用层导致的网络拥塞，效果较差。因此，本发明在基于滑动窗口的SOAP消息传输过程中，使用了一种应用层的拥塞控制机制，以保证SOAP消息传输的畅通。

在TCP的拥塞控制中，一般采用：慢启动、加速递减以及拥塞避免三种技术。但在应用层，其所处协议栈层次较高，如果仍然采用TCP中使用的三种技术，频繁改变窗口大小，反而会导致效率低下。因而，本发明提出了一种控制应用层滑动窗口拥塞的方法，如图10所示，具体方法如下：

1、在发送方接收方三次握手建立连接时，确定双方可以接受的发送窗口最大值(MAX_SIZE)，并且设置发送窗口大小(SENDER_SIZE)＝MAX_SIZE，接收窗口大小(RECEIVER_SIZE)＝MAX_SIZE；

2、按照设置的发送窗口大小，使用滑动窗口进行SOAP消息传输；

3、发送方每接收到一个非请求重发数据的响应消息的同时，判断一下此时发送窗口大小(SENDER_SIZE)是否小于发送窗口最大值(MAX_SIZE)，如果小于，则SENDER_SIZE＝SENDER_SIZE+1；否则，保持发送窗口大小不变；

4、在传输过程中，如果发送方发出的SOAP消息连续重传次数小于等于某个经验值(例如3次)，则认为网络传输通畅，重复执行第2～第4步；

如果发送方发出的某SOAP消息连续重传次数大于经验值(例如3次)，则认为出现网络拥塞，数据传输暂停DELAY_T时间，设置SENDER_SIZE＝(SENDER_SIZE+1)/2；这时接收方如果长时间没有收到消息，将休眠，直到被发送方唤醒；

5、判断暂停时间是否到？如果没有到，继续暂停；如果时间到，则继续执行第2～第5步直到数据传输完毕，结束。

在该拥塞控制方法中，DELAY_T是数据传输暂停时间，依赖于当前网络的拥塞时间，其值不应该太大。如果接收方长时间没有收到发送方的数据，将进入睡眠或者终止状态，然后由接收方唤醒。

拥塞控制方法是基于滑动窗口的SOAP消息传输方法中的一个子流程。

下面以采用选择重传ARQ协议来实现滑动窗口，采用SOAP withAttachement(SwA)规范对SOAP消息附件进行封装，HTTP协议作为传输协议进行数据传输为例，举例说明本发明基于滑动窗口实现SOAP消息传输的方法。

一、在SOAP消息传输开始前的一些约定：

1.接收方窗口大小W_R不能超过发送方窗口大小W_T；

2.发送方和接收方滑动窗口中每次只能存储同一个数据的切片，如果一个数据太小，不足以装满滑动窗口，可以将多个数据打包组合成一个大数据放入滑动窗口中进行传输；

3.为了减少不必要的传输和多余的数据构造和解析，接收方只是向发送方发送确认消息(ACK)，不发送否认消息(NAK)；

4.接收方发送的响应消息分两种：ACK1和ACK2，ACK1是对消息序号连续的最后一个数据消息进行确认，ACK2是对消息序号不连续的单个数据消息进行确认，发送方收到ACK1之后滑动窗口向前滑动，发送方收到ACK2之后滑动窗口不滑动，只改变ACK2对应的数据消息参数；

5.接收方可以接收序号不连续，但仍然处在接收窗口中的数据切片，接收窗口满之后才可以一起提交接收到的数据；

6.对于发送方的每个窗格需要有两个标志：Tag1和Tag2。Tag1是相应数据消息是否已经发送标志，用以区分已发送过的数据消息和未发送过的数据消息，Tag2是相应数据消息是否已经发送并收到确认标志，用以区分接收方是否已经收到该数据消息；

7.接收方的超时时间用来确定发送方是否还在工作，如果很久没有收到发送方发来的消息，则认为发送方失效，结束数据接收，因此该超时时间比较长。

二、发送方设计和实现

假设和条件：发送方滑动窗口大小为n，滑动窗口为数组window[n]，每个数据切片大小为k，超时时间为OverTime，超时重传次数为t1，读取数据重试次数t2。发送方主要步骤如下：

1 获取所要传输的第一个数据；

2 读数据的前0-n片至滑动窗口，如果数据切片数目小于n，则只将该数据读完，不再读下一个待发送的数据。对每个滑动窗格window[i]，将Tag1设置为false，发送次数time(window[i])＝0，并初始化定时器任务。{初始化滑动窗口}；

3 对于滑动窗口中所有Tag1＝false的窗格，执行下面操作；

4 对于窗格window[i]，发送次数time(window[i])＝time(window[i])+1；

4.1 若time(window[i])＞t1，跳转到第9步。{数据传输结束：传输重试次数超过次数上限，认为网络无法连通}；

4.2 若time(window[i])(＝t1，将其数据发送出去，Tag1＝true，并设置超时定时器。{滑动窗口的数据发送操作}；

5 等待{等待以下三个事件中最先出现的一个}；

6 若收到某个数据消息m的响应消息ACK1：

6.1 若m不在滑动窗口内或者ACK不是对当前数据的确认，不处理(说明接收方的ACK延时时间太长)；

6.2 若m所包含的是当前传输的数据的最后一个切片，并且当前传输的数据不是最后一个数据，获取所要传输的下一个数据，转到(2)；

6.3 若m所包含的是当前传输的数据的最后一个切片，并且当前传输的数据是最后一个数据，转到第10步{数据传输正常结束}；

6.4 若m在滑动窗口内，滑动窗口向前滑动至数据m+1位置处，读取后继数据切片；

6.4.1如果读取数据成功，初始化每个新读入滑动窗口的数据切片，转到(3)：

6.4.2如果读取数据失败，失败原因是IO错误，则重试；

6.4.2.1若在t1次数之内重试成功，转到(6.4.1)；

6.4.2.2若在t1次数之内重试失败，转到第9步。{数据传输结束：读数据重试次数超过最大次数}；

7 若收到某个数据消息m的响应消息ACK2，当m不在滑动窗口内或者ACK不是对当前数据的确认，不处理(说明接收方的ACK延时时间太长)，否则，将Tag1、Tag2设置为true，滑动窗口不滑动；

8 若窗格window[i]超时计时器超时，若Tag2＝false，设置Tag1＝false，转到(3){重传数据}；

9 数据传输失败并结束；

10 数据传输成功并结束。

三、接收方设计和实现

假设和条件：接收滑动窗口大小为1，数据切片大小为k，写数据重试次数t1，发送ACK重试次数t2。接收方主要步骤如下：

1 初始化接收窗口位置，设置超时时间{初始化数据接收状态}；

2 等待；{等待以下3、4两个事件中最先出现的一个}

3 当收到一个数据切片时，重新设置超时时间，检查有无传输差错，检查其是否在接收窗口内；

3.1 如果检查发现有传输错误，丢弃数据切片，转到(2)；

3.2 如果检查发现数据消息序号小于接收窗口或者收到的数据不是接收窗口正在接收的数据，发送ACK1，转到(2){说明接收方没有收到响应消息}；

3.3 如果检查发现数据消息序号大于接收窗口，丢弃数据切片，转到(2)；

3.4 如果检查正确无误，放入滑动窗口；

3.4.1如果接收到的数据消息使得滑动窗口前面连续的几个数据消息都收到，将前几个数据消息进行写数据操作；

3.4.1.1若写数据重试次数超过t1，转到第5步，{数据传输结束，认为数据接收方无法接收数据}；

3.4.1.2若写数据成功，构造新的ACK1，判断数据是否传输完毕

3.4.1.2.1如果该数据尚未传输完毕，发送ACK1，转到(2)；

3.4.1.2.2如果该数据已经传输完毕，但还有下一个数据等待接收，发送ACK1，转到(1)；

3.4.1.2.3如果所有数据都已经传输完毕，发送ACK1，第6步{接收方正常结束}；

3.4.2如果接收到的数据消息在滑动窗口中，但并不连续，发送ACK2，只对该数据消息进行确认，转到(2)；

4 如果等待时间超过OverTime，ACK1发送次数+1，判断发送ACK1次数与t2大小，若发送ACK次数＞t2，跳转到第5步。{数据传输结束：传输重试次数超过RetryTime，认为网络无法连通}；否则，发送响应消息ACK1；

5 数据传输失败并结束；或数据传输成功并结束。

图11和图12是使用本发明公开的基于滑动窗口传输SOAP消息方法在不同的参数下的实验结果。

测试环境如下：

待传输数据大小：53.248M；硬件配置：CPU：Intel Pentium IV 3.0，内存：1GB，硬盘：可用空间2.0G，网络带宽：100Mbps；软件配置：JDK：1.4.2，操作系统：Windows XP，传输协议：HTTP1.0，SOAP引擎：XLinker，Web服务器：Tomcat-5.0.19。

图11显示了滑动窗口传输时间与滑动窗口大小和网络传输时延(RTT)的关系。其中，横坐标表示滑动窗口大小，纵坐标表示传输所用时间，该实验采用的是800K的切片大小，图中最下面的线条为网络传输时延＜1ms的结果，中间的线条为网络传输时延＝200ms的结果，最上面的线条为网络传输时延＝600ms的结果。

图12显示了滑动窗口传输时间与数据切片长度的关系。可以看出在不考虑其他因素的情况下，切片长度越大，传输时间越短，并且切片长度增加到一定程度时，对传输时间的影响非常小。显然，切片长度受到内存、传输并发数、CPU处理能力等的限制，因此必须根据实际需要选择合适的值。

上面两个试验结果表明，基于滑动窗口的SOAP消息传输方法能大大提高SOAP消息传输效率。

本发明的优点：

1、本发明将数据分成切片，并通过滑动窗口同时传输多个数据切片，充分利用了网络带宽，大大提高了SOAP消息传输的效率。

2、SOAP消息级滑动窗口是一种应用层滑动窗口机制，因而具有很大的灵活性，可以通过配置文件来对其进行参数配置，使其达到效率最优化。

3、提供了一种应用层拥塞控制机制，从根本上解决了SOAP消息发送太快对网络造成的拥塞问题。

4、该SOAP滑动窗口机制对数据传输提供了可靠性保证。充分考虑了滑动窗口实现时可能出现的各种异常情况，对每种情况都作了分析。

5、由于滑动窗口消息所带的数据长度可以不是固定的，只要在SOAP体中指明当前SOAP消息所带数据长度即可。这种方式使得采用SOAP传输大尺寸数据和可变大小数据以及大小不断变化数据变得非常容易。

6、本发明不依赖于具体的传输协议，可用于各种传输协议，包括TCP、UDP、HTTP等，通过与HTTP协议的结合，能够使得数据传输能够穿越一般防火墙，便于实现异构网络之间的互联互通。

7、本发明SOAP消息级滑动窗口与常用Web服务规范都是兼容的，可以使用安全规范WS-Security等对滑动窗口中的每个数据切片进行加密，可以使用SOAP with Attachment，XOP，MTOM等规范将每个数据切片封装到SOAP消息中。

以上所述是本发明的具体实施例及所运用的技术原理，任何基于本发明技术方案基础上的等效变换，均属于本发明保护范围之内。

Claims

1、一种基于滑动窗口的SOAP消息传输方法，其特征在于：将SOAP消息待传输的数据切片，将分割后得到的数据切片作为附件封装到SOAP消息中，再将包含有数据切片附件的SOAP消息装入滑动窗口中，使用滑动窗口传输包含有数据切片的SOAP消息。

2、根据权利要求1所述的基于滑动窗口的SOAP消息传输方法，其特征在于：所述滑动窗口中的SOAP消息分为两种：SOAP滑动窗口数据消息和SOAP滑动窗口响应消息；

SOAP滑动窗口数据消息由发送方发出，每个数据消息中包含一个或多个数据切片的数据，切片大小可以任意也可以固定，按照约定的SOAP消息附件规范封装入SOAP消息中；在SOAP消息主体中指明该数据的基本信息，如：SOAP消息编号(SOAPID)、待发送的数据编号(DataNumber)、切片编号(SliceNumber)、数据切片个数、每个数据切片的大小、所采用的SOAP附件封装规范、以及是否是当前正在传输的数据的最后一个数据切片(isLastSlice)和是否是最后一个数据(isLastData)；

SOAP滑动窗口响应消息由接收方发出，是对发送方发出的数据消息的确认。响应消息的SOAP消息主体中包含如下信息：SOAP消息编号(SOAPID)，已确认的数据编号(ACKDataNumber)、已确认的数据切片编号(ACKSliceNumber)、是否是当前正在传输的数据的最后一个数据切片(isLastSlice)、是否是最后一个数据(isLastData)、响应消息类型(ACKType)以及具体响应信息(ResponseInfo)。

3、根据权利要求2所述的基于滑动窗口的SOAP消息传输方法，其特征在于：在建立了数据切片、滑动窗口的概念后，本发明基于滑动窗口的SOAP消息传输方法包括以下步骤：

4、根据权利要求3所述的基于滑动窗口的SOAP消息传输方法，其特征在于：发送方基于滑动窗口的SOAP消息传输过程，包括以下步骤；

H、等待接收方发送的SOAP滑动窗口响应消息，并计时；

J、接收SOAP滑动窗口响应消息，并解析SOAP滑动窗口响应消息，获取响应消息：

5、根据权利要求3所述的基于滑动窗口的SOAP消息传输方法，其特征在于：接收方基于滑动窗口的SOAP消息传输过程包括以下步骤；

A、首先，接收方通过三次握手方式与发送方建立连接，三次握手之后，根据约定初始化接收方滑动窗口，启动定时器；

B、等待发送方发送的SOAP滑动窗口数据消息；

D、接收发送方发送的SOAP滑动窗口数据消息；

F、解析接收到的SOAP滑动窗口数据消息，获取数据切片；

G、将数据切片放入接收方接收滑动窗口中；

H、判断是否接收到序号连续的前几个数据？如果是，则将连续的前几个数据切片写入文件系统或其他数据接收目的地；如果不是，则直接执行下一步；

J、采用具体传输协议发送SOAP滑动窗口响应消息；

6、根据权利要求3或4或5所述的基于滑动窗口的SOAP消息传输方法，其特征在于：该SOAP消息传输方法还包括拥塞控制内容，其具体方法如下：

A、在发送方接收方三次握手建立连接时，确定双方可以接受的发送窗口最大值(MAX_SIZE)，并且设置发送窗口大小(SENDER_SIZE)＝MAX_SIZE，接收窗口大小(RECEIVER_SIZE)＝MAX_SIZE；

B、按照设置的发送窗口大小，使用滑动窗口进行SOAP消息传输；

C、发送方每接收到一个非请求重发数据的响应消息的同时，判断一下此时发送窗口大小(SENDER_SIZE)是否小于发送窗口最大值(MAX_SIZE)，如果小于，则SENDER_SIZE＝SENDER_SIZE+1；否则，保持发送窗口大小不变；

D、在传输过程中，如果发送方发出的某个SOAP消息连续重传次数没有超过设置的经验值(例如3次)，则认为网络传输通畅，重复执行第B～第D步；

如果发送方发出的某SOAP消息连续重传次数超过经验值(例如3次)，则认为出现网络拥塞，数据传输暂停DELAY_T时间，设置SENDER_SIZE＝(SENDER_SIZE+1)/2；这时接收方如果长时间没有收到消息，将休眠，直到被发送方唤醒；

E、判断暂停时间是否到？如果没有到，继续暂停；如果时间到，则继续执行第B～第E步直到数据传输完毕，结束。