CN102457573A - 数据通信方法和信息处理设备 - Google Patents
数据通信方法和信息处理设备 Download PDFInfo
- Publication number
- CN102457573A CN102457573A CN2011103195811A CN201110319581A CN102457573A CN 102457573 A CN102457573 A CN 102457573A CN 2011103195811 A CN2011103195811 A CN 2011103195811A CN 201110319581 A CN201110319581 A CN 201110319581A CN 102457573 A CN102457573 A CN 102457573A
- Authority
- CN
- China
- Prior art keywords
- data
- information
- client
- tcp
- parts
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/14—Multichannel or multilink protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
提供了一种在第一信息处理设备和第二信息处理设备之间建立多个TCP(传输控制协议)连接并且通过多个所建立的TCP连接来传递为每个规定单元划分的每条数据的数据通信方法。在该方法中,所述第一信息处理设备通过向所述第二信息处理设备通知表示要与所述第二信息处理设备建立的TCP连接数目的上限的连接上限信息、并且通过改变要被通知的所述连接上限信息来动态地改变与所述第二信息处理设备的TCP连接的数目。
Description
技术领域
本公开涉及一种数据通信方法和信息处理设备,其能够在服务器设备和客户端设备之间建立多个TCP(传输控制协议)连接并且通过所述多个TCP连接来传递为每个规定单元划分的每条数据。
背景技术
在现有技术中,存在在因特网上通过HTTP(超文本传输协议)传递来自服务的网页和内容的广泛使用的方法。例如,可能通过HTTP执行数据的下载(GET)或上载(PUT)。
一般而言,在单个TCP上执行HTTP。TCP是能够进行异步双向通信的传输。在HTTP中,作为客户端的信息处理设备和作为服务器的信息处理设备通过单个TCP连接交换对下载(GET)或上载(PUT)数据的请求或者对请求的答复。具体地,客户端传送上载请求(PUT请求),并且然后在PUT请求之后传送要上载的数据。另一方面,当客户端传送下载请求(GET请求)时,服务器传送对GET请求的答复,并且在答复之后传送要下载的数据。
这里,在带宽充分大并且其中延迟较大的环境下每一个TCP的吞吐量依赖于TCP的流控制的方法。这里,通过每套接字(socket)/RTT(往返时间,分组的往返所必要的时间)的接收缓冲器大小来获得最大吞吐量。当由于上述因素限制TCP的最大吞吐量时,在带宽充分大并且其中延迟较大的环境下,存在不能充分展示链路的原本能力的担忧。
由于该原因,已建议了SPDY,其是替代HTTP作为因特网内容的通信协议的标准(例如,参考在因特网URL:http://www.chromium.org/spdy(在2010年10月18日搜索的)上的在线文档“SPDY”)。在SPDY中,改进在于通过改变HTTP的层而可能有效地甚至在一个TCP上传送因特网的各种内容。SPDY提供了解决由HTTP导致的问题的线索(例如,需要完成请求序列中的数据通信等等)以及使得浏览器能够执行有效的预读取的线索。
此外,已提出了利用HTTP通过使用多个TCP连接并行传送数据的方法(例如,参照日本未审专利申请公布No.2005-57482)。
发明内容
然而,预读取仅在能够进行预读取的情境中是有效的,并且在许多情况下,难以执行预读取。在因特网URL:http://www.chromium.org/spdy(在2010年10月18日搜索的)上的在线文档“SPDY”的描述中,难以传送比TCP的吞吐量的上限大的数据。
此外,在日本未审专利申请公布No.2005-57482中,假定同时发送的数据流是单个的。因而,难以同时处理多个请求以及改变其顺序。此外,由于TCP连接的数目是恒定的,所以难以动态地限制资源以及应对环境改变。此外,在日本未审专利申请公布No.2005-57482中,没有考虑在TCP断开连接时的数据的恢复。
考虑到上述情形,期望提供一种能够基于HTTP增加数据通信速度的数据通信方法和信息处理设备。
根据本公开的实施例,提供了一种在第一信息处理设备和第二信息处理设备之间建立多个TCP(传输控制协议)连接并且通过多个所建立的TCP连接来传递为每个规定单元划分的每条数据的数据通信方法。
所述第一信息处理设备通过向所述第二信息处理设备通知连接上限信息、并且通过改变被通知的连接上限信息来动态地改变与所述第二信息处理设备的TCP连接数目,所述连接上限信息表示要与所述第二信息处理设备建立的TCP连接的数目的上限。
根据本公开的所述实施例,通过动态地增加或减少TCP连接的数目,能够控制吞吐量。例如在以下情况中,对TCP连接的数目的动态控制是有利的。在其中单个所述第一信息处理设备(服务器设备)和多个所述第二信息处理设备(客户端设备)几乎同时执行通信的情况下,由于所述第一信息处理设备的处理能力的限制,每一个第二信息处理设备能够提供的吞吐量是有限的。当第二信息处理设备的数目增加时,通过降低到所连接的第二信息处理设备的吞吐量,可能使它们等于到新的第二信息处理设备的吞吐量。由此,可能在多个第二信息处理设备间同等地执行服务。
优选地,所述第一信息处理设备应依据连接上限信息的改变而顺序地更新命令顺序信息,并且应该向所述第二信息处理设备传送所述信息。
优选地,所述第二信息处理设备应该基于所接收的命令顺序信息识别出来自所述第一信息处理设备的最近的连接上限信息。
当由所述第一信息处理设备传送的多条不同连接上限信息通过不同的TCP连接到达所述第二信息处理设备时,所述多条连接上限信息的到达顺序可能不同于其传送的顺序。在这种情况下,即使当随后传送的最近的连接上限信息比先前传送的连接上限信息早到达时,所述第二信息处理设备也能够基于所述命令顺序信息识别出最近的连接上限信息的通知。
优选地,所述第一信息处理设备应该向每条已划分数据的头部添加连接上限信息和命令顺序信息,并且应该向所述第二信息处理设备传送所述信息。
当连接上限信息和命令顺序信息被添加到头部时,所述第一信息处理设备不必与已划分数据分开地向所述第二信息处理设备传送请求以通知连接上限信息。此外,所述第二信息处理设备能够在必要时参考各条已划分数据的头部直接识别出连接信息的更新。
优选地,所述第二信息处理设备应该向所述第一信息处理设备传送包括用于指定数据的数据指定信息的传送请求。
优选地,所述第一信息处理设备应该将在所接收的传送请求中包括的数据指定信息所指定的数据划分成用于每个规定单元的各条,应该将数据指定信息添加到每条已划分数据的头部,并且应该将所述数据传送到所述第二信息处理设备。
所述第二信息处理设备能够参考添加到每条已划分数据的头部的数据指定信息而不管各条已划分数据的接收顺序来恢复具有相同数据指定信息的每条已划分数据的数据。例如,当下载多条数据时,所述第二信息处理设备可能按照对一个数据被划分到的数据条与另一个数据被划分到的数据条进行混合的顺序来接收所述一个数据被划分到的数据条和所述另一个数据被划分到的数据条。即使在这种情况下,所述第二信息处理设备也能够参考用于指定每条数据的数据指定信息来恢复用于具有相同数据指定信息的每条已划分数据的多条数据。
优选地,所述第一信息处理设备应该进一步将用于识别没有被划分的数据的上下文的上下文识别信息添加到每条已划分数据的头部。
由此,不管接收各条已划分数据的顺序如何,所述第二信息处理设备能够参考上下文识别信息来按照正确顺序恢复数据。
根据本公开的另一个实施例,一种信息处理设备包括能够连接到网络的网络连接部件和改变装置。
当通过所述网络连接部件建立与不同信息处理的多个TCP(传输控制协议)连接、并且通过多个所建立的TCP连接传递为每个规定单元划分的每条数据时,所述改变装置通过向不同信息处理通知连接上限信息、并且通过改变要通知的连接上限信息来动态地改变与不同信息处理的TCP连接的数目,所述连接上限信息表示要与不同信息处理建立的TCP连接的数目的上限。
根据本公开的该实施例,能够基于HTTP增加数据通信的速度。
附图说明
图1是图示根据本公开的实施例的数据通信系统的配置的图;
图2是图示客户端设备和服务器设备的功能性配置的框图;
图3是图示在客户端设备从服务器设备下载数据的情况下的数据通信方法的顺序图;
图4是图示在客户端设备向服务器设备上载数据的情况下的数据通信方法的顺序图;
图5是图示在数据通信的动作(下载)中在增加TCP连接的数目的情况下的数据通信方法的顺序图;
图6是图示在数据通信的动作(上载)中在增加TCP连接的数目的情况下的数据通信方法的顺序图;
图7是图示在数据通信的动作中在减少TCP连接的数目的情况下的数据通信方法的顺序图;
图8是图示在客户端设备向服务器设备传送GET请求并且在从服务器设备获取响应之前进一步传送PUT请求的情况下的数据通信方法(流水线技术:pipelining)的顺序图;
图9是图示在客户端设备向服务器设备传送GET请求并且在从服务器设备获取响应之前进一步传送分开的GET请求的情况下的数据通信方法(流水线技术)的顺序图;
图10是图示客户端设备的硬件配置的框图;以及
图11是图示服务器设备的硬件配置的框图。
具体实施方式
在下文中,将参考附图描述本公开的实施例。
数据通信系统的配置
图1是图示根据本公开的实施例的数据通信系统的配置的图。
信息处理系统100具有服务器设备300和一个或多个客户端设备200。客户端设备200和服务器设备300通过全局网络101彼此连接通信。应指出的是,在下文中将仅仅描述多个客户端设备200中的一个客户端设备200。
客户端设备200和服务器设备300中的每一个被配置为包括诸如PC(个人计算机)的信息处理设备,并且能够通过使用TCP连接而通过HTTP来传递数据。
例如,客户端设备200通过HTTP向服务器设备300传送数据上载请求(在下文中称为“HTTP PUT请求”或简称为“PUT请求”,并且随后向服务器设备300传送要上载的数据。此外,客户端设备200通过HTTP向服务器设备300传送数据下载请求(在下文中称为“HTTP GET请求”或简称为“GET请求”。当接收到GET请求时,服务器设备300向客户端设备200传送要下载的数据。以这样的方式,客户端设备200能够向服务器设备300上载数据和从服务器设备300下载数据(所谓的云计算)。
客户端设备和服务器设备的功能性配置
图2是图示客户端设备和服务器设备的功能性配置的框图。
客户端设备200具有客户端侧并行通信部件201、客户端侧收集通信部件202、客户端侧分发通信部件203、客户端侧通信部件204、浏览器205和UI(用户接口)206。
UI 206是用于在客户端设备200和用户之间交换信息的接口。
浏览器205响应于从用户接收通过UI 206输入的请求而执行HTTP处理,并且执行用于分析内容的处理等。
客户端并行通信部件201通过建立多个TCP连接而执行用于发起并行通信的处理等。
客户端侧分发通信部件203执行用于通过使用多个TCP连接经由客户端侧通信部件204来分发传送HTTP事务的处理等。
客户端侧收集通信部件202执行用于通过收集由客户端侧通信部件204经由多个TCP连接接收的内容(块)而执行恢复的处理等。
服务器设备300具有服务器侧并行通信部件301、服务器侧收集通信部件302、服务器侧分发通信部件303、服务器侧通信部件304、web服务器306和后端服务305。
Web服务器306基于HTTP执行用于在客户端设备200的浏览器205上显示数据等的处理。
后端服务305执行对用户通过浏览器205请求的命令的处理等。
服务器侧并行通信部件301(改变装置)执行用于响应于从客户端侧并行通信部件201接收并行通信的请求而指定适合于传送和接收数据的TCP连接数目的上限的处理等。
服务器侧分发通信部件303执行用于通过使用多个TCP连接经由服务器侧通信部件304分发传送HTTP事务的处理等。
服务器侧收集通信部件302执行用于通过收集由服务器侧通信部件304经由多个TCP连接接收的内容(块)而执行恢复的处理等。
数据通信方法
接下来,将描述根据实施例的数据通信方法。将以下列项的次序给出描述。
1.在客户端设备200从服务器设备300下载数据的情况下的数据通信方法;
2.在客户端设备200向服务器设备300上载数据的情况下的数据通信方法;
3.在数据通信的动作(下载)中增加TCP连接数目的情况下的数据通信方法;
4.在数据通信的动作(上载)中增加TCP连接数目的情况下的数据通信方法;
5.在数据通信的动作中减少TCP连接数目的情况下的数据通信方法;
6.在客户端设备200向服务器设备300传送GET请求并且在从服务器设备300获取响应之前进一步传送PUT请求的情况下的数据通信方法(流水线技术);
7.在客户端设备200向服务器设备300传送GET请求并且在从服务器设备300获取响应之前进一步传送分开的GET请求的情况下的数据通信方法(流水线技术);
8.从TCP连接的无意连接断开中恢复数据的方法(下载时);
9.从TCP连接的无意连接断开中恢复数据的方法(上载时)。
1.在客户端设备从服务器设备下载数据的情况下的数据通信方法
当从浏览器205接收到HTTP请求(内容接收请求)时,客户端侧并行通信部件201按照以下次序开始并行通信:传送HTTP GET请求(步骤S101);接收HTTP响应头部部分(步骤S102);建立第二和随后的TCP连接(步骤S105至S107);以及向客户端侧收集通信部件202和客户端侧分发通信部件203通知已建立的TCP连接。
应注意的是,在所有情况下,从客户端设备200向服务器设备300发起下面将描述的TCP连接的建立。原因在于增加从客户端设备200到服务器设备300的连接被建立的可能性。一般而言,用于允许建立连接的环境条件比用于等待连接的环境条件更宽松。例如,假定下面的环境:在设备和网络101之间存在用于控制从外部到内部的通信的网关。网关通过阻止不适当的通信来保持内部环境健康。为了等待连接,网关应该允许通信到总是固定的端口,因而有必要提供单独的计数器措施以阻止到该端口地址的不期望通信。另一方面,为了建立连接,仅在存在从内部到外部的通信时,可以仅允许从外部到内部的用于其答复的通信。作为答复阻止从不适当发送方发送的通信是容易的。如上所述,通过设置容易构建为客户端侧条件的环境,该方法容易地被应用于作为正常用户访问的服务的模型。
图3是图示在客户端设备从服务器设备下载数据的情况下的数据通信方法的顺序图。
此外,图中的每个实线箭头表示通过客户端侧通信部件204和服务器侧通信部件304在客户端侧并行通信部件201和服务器侧并行通信部件301之间的通信。图中的每个点划线箭头表示通过客户端侧通信部件204和服务器侧通信部件304在客户端侧收集通信部件202和服务器侧分发通信部件303之间的通信。
当从浏览器205接收到内容接收请求时,客户端侧并行通信部件201建立第一TCP连接#0(在下文中称为“主连接#0”)。客户端侧并行通信部件201生成HTTP GET请求,其中向其传输编码头部(在下文中简称为“TE头部”)分配值“mtcp”。客户端侧并行通信部件201通过客户端侧通信部件204使用主连接#0来向服务器设备300传送所生成的HTTP GET请求(步骤S101)。
当通过服务器侧通信部件304从客户端侧并行通信部件201接收到HTTP GET请求时,服务器侧并行通信部件301向后端服务305发出数据传送请求。通过请求的URL来指定目标数据的位置。后端服务305将从客户端设备200请求的数据存储在服务器侧分发通信部件303的发送缓冲器(图中未示出)中。
然后,服务器侧并行通信部件301通过服务器设备300发出独特的会话id(session-id)。此外,服务器侧并行通信部件301确定适合于传送HTTP GET请求所请求下载的数据的TCP连接的数目的上限(例如,在每一个TCP 3Mbps以8Mbps流送内容的环境下,数目是3)。服务器侧并行通信部件301生成HTTP响应(200OK)作为对HTTP GET请求的响应,其表示会话id和TCP连接数目的上限值。向HTTP响应(200OK)的TE头部分配值“mtcp”。服务器侧并行通信部件301通过服务器侧通信部件304使用主连接#0来向客户端设备200传送所生成的HTTP响应(200OK)(步骤S102)。然后,服务器侧并行通信部件301向服务器侧分发通信部件303通知由接收的HTTP GET请求所请求下载的数据。
这里,HTTP响应(200OK)包括MTCP会话头部。MTCP会话头部的语法如下:“MTCP-Session”“:”session-id“,”tid[“,”con]。这里“session-id”是指定属于相同会话的连接的整数。“tid”(传输ID,数据指定信息)是用于指定要传送的数据的整数,即指定事务的整数,并且在单个会话的持续期间使用唯一的值。“con”(连接上限信息)是一整数,该整数表示服务器设备300通过其能够对应于客户端设备200的TCP连接数目的上限(最大数目)。此外,“con”对于特定会话中的第一事务的情况是必不可少的,但是如果其使用与先前值相同的值,则可以被省略。此外,服务器设备300确定连接的适当数目(连接数目的上限)。原因在于与客户端设备200相比,应该处理到多个客户端设备200的多个连接的服务器设备300容易受处理能力的限制所影响。
在图的步骤S102中,示出了其中设置“tid=1”和“con=4”的示例。也就是说,能够看出,该事务是第一事务(“tid=1”),并且服务器设备300通过其能够对应于客户端设备200的TCP连接数目的上限是4(“con=4”)。
服务器侧分发通信部件303将由后端服务305存储在发送缓冲器中的数据划分成块(chunk),并且分别向块分配顺序号。然后,服务器侧分发通信部件303通过服务器侧通信部件304使用主连接#0向设备200传送被分配顺序号的多个块(步骤S103和S104)。此外,直到客户端侧并行通信部件201建立第二和随后的(在该示例中,最大4)TCP连接为止,服务器侧分发通信部件303通过服务器侧通信部件304使用主连接#0向客户端设备200传送相应块。
这里,在每个块中写入块头部。块头部的语法如下:chunk-size;seq=chunk-seq[;con=n;cseq=cmd-seq][;start=start-seq;tid=t-id]。这里,“chunk-seq”表示相应块的长度。“chunk-seq”(上下文识别信息)表示用于识别在没有被划分的原始数据中的位置关系的块顺序号(序列号)。此外,第一块的“chunk-seq”是随机值,并且即使随后的块通过任何TCP连接(在此,主连接#0)传递,在其中也写入在数据划分前在其顺序中递增的值。作为被写入为开始指令的值的“start-seq”表示在事务中的第一块的chunk-seq。“tid”表示包括在HTTP响应(200OK)中的tid的值。此外,后面将描述“n”和“cmd-seq”。
在图的步骤S103中,示出了其中设置“chunk-seq:1a21”、“start-seq:1a21”和“tid=1”的示例。也就是说,可以看出,块的顺序号是1a21(“chunk-seq:1a21”),事务中的第一块的顺序号是1a21(“start-seq:1a21”),以及事务是第一事务(“tid=1”)。然后,在图的步骤S104中,在具有顺序号1a21的块之后,传送具有顺序号1a22(“chunk-seq:1a22”)的块。应该注意的是,在图中,在步骤S104中传送的块的块头部被部分省略。
客户端侧收集通信部件202通过客户端侧通信部件204使用主连接#0接收从服务器设备300传送的相应块。客户端侧收集通信部件202具有接收缓冲器(图中未示出),并且临时将所接收的块存储在接收缓冲器中。
另一方面,当通过客户端侧通信部件204从服务器侧并行通信部件301接收到HTTP响应(200OK)时(步骤S102),客户端侧并行通信部件201检查MTCP会话头部中包括的“con”的值。也就是说,客户端侧并行通信部件201检查服务器设备300通过其能够对应于客户端设备200的TCP连接的数目的上限。当确定“con”是2或更大时,客户端侧并行通信部件201建立第二和随后的TCP连接(下文中称为“辅连接”)。在该示例中,由于“con=4”,所以客户端侧并行通信部件201建立包括主连接#0的总共4个TCP连接。也就是说,客户端侧并行通信部件201建立3个辅连接#1、#2和#3。客户端侧并行通信部件201通过客户端侧通信部件204分别使用所建立的辅连接#1、#2和#3来并行地向服务器侧并行通信部件301传送HTTP CONNECT(HTTP连接)请求(步骤S105至S107)。
此外,正常情况下,客户端侧并行通信部件201建立辅连接,使得连接的数目达到由在MTCP会话头部中包括的“con”的值指定的上限。然而,例如,在缺乏对单独处理足够的处理能力这样的情况下,可能难以建立指定数目的辅连接。在这种情况下,客户端侧并行通信部件201可以建立在上限的范围中可允许的数目的辅连接。
在此,客户端侧并行通信部件201向HTTP CONNECT请求的MTCP会话头部的值分配在步骤S102接收的会话id,并且向TE头部分配“mtcp”。
服务器侧并行通信部件301通过服务器侧通信部件304分别使用辅连接#1、#2和#3接收HTTP CONNECT请求。服务器侧并行通信部件301参考通过由所接收的HTTP CONNECT请求指示的会话id确定辅连接属于哪个主连接。在该示例中,服务器侧并行通信部件301通过参考由分别通过辅连接#1、#2和#3接收的HTTP CONNECT请求指示的会话id确定辅连接#1、#2和#3属于主连接#0。此外,当缺乏相应的会话id时,或当辅连接的数目超过上限时,服务器侧并行通信部件301通过服务器侧通信部件304向客户端设备200传送错误。之后,服务器侧并行通信部件301通过服务器侧通信部件304分别使用辅连接#1、#2和#3并行地向客户端设备200传送HTTP响应(200OK)(步骤S108至S110)。然后,服务器侧并行通信部件301向服务器侧收集通信部件302和服务器侧分发通信部件303通知所建立的辅连接#1、#2和#3。
当通过客户端侧通信部件204接收到相应HTTP响应(200OK)时,客户端侧并行通信部件201向客户端侧收集通信部件202和客户端侧分发通信部件203通知所建立的辅连接#1、#2和#3。至此完成开始并行通信的处理。
当从服务器侧并行通信部件301接收到辅连接#1、#2和#3的建立的通知时,服务器侧分发通信部件303通过服务器侧通信部件304使用任意TCP连接(主和辅连接#0、#1、#2和#3)并行地向客户端设备200传送被分配顺序号的多个块(步骤S111至S120)。
此外,服务器侧分发通信部件303监视用于每个TCP连接(主和辅连接#0、#1、#2和#3)的发送套接字缓冲器。然后,当在任意一个TCP连接的发送套接字缓冲器中出现未使用空间时,服务器侧分发通信部件303可以进一步将属于服务器侧分发通信部件303的发送缓冲器的未发送数据划分成块,并且可以将数据移到出现未使用空间的发送套接字缓冲器。
在图中,服务器侧分发通信部件303向服务器侧通信部件304传送预先在步骤S103和S104中通过“chunk-seq:1a21”和“chunk-seq:1a22”指示的相应块。因此,由服务器侧分发通信部件303连续向服务器侧通信部件304传送的块的每个“chunk-seq”(顺序号)可以依次地用1a23、1a24、1a25、...、1a2a、1a2b、和1a2c表示。例如,作为在步骤S112中传送的块的块头部,设置了“chunk-seq:1a24”、“start-seq:1a21”和“tid=1”。也就是说,可以看出,块的顺序号是1a24(“chunk-seq:1a24”),事务中的第一块的顺序号是1a21(“start-seq:1a21”),以及所述事务是第一事务(“tid=1”)。应该注意的是,在图中,在步骤S111至S120中传送的块的块头部被部分省略。此外,在下面的图中,一些块头部被部分省略。
客户端侧收集通信部件202通过客户端侧通信部件204使用主和辅连接#0、#1、#2和#3接收从服务器设备300传送的相应块。客户端侧收集通信部件202不管使用哪个TCP连接(主和辅连接#0、#1、#2和#3)都将所接收的块临时存储在接收缓冲器中。客户端侧收集通信部件202收集块到某种程度,并且然后向浏览器205提供顺序号连续的块序列作为所接收数据。客户端侧收集通信部件202重复该处理。此外,如果连接没有断开但是存在其中顺序号被省略的部分,则客户端侧收集通信部件202等待被省略块从服务器设备300的到达,同时将在省略之后接收的块存储在接收缓冲器中。
服务器侧分发通信部件303通过服务器侧通信部件304向客户端设备200传送单个数据被划分成的多个块中的被分配最后顺序号的块(步骤S120)。之后,服务器侧分发通信部件303通过服务器侧通信部件304使用主连接#0向客户端设备200传送零块(步骤S121)。
这里,零块是仅具有块头部而没有数据的块。零块的形式例如如下:0;[con=n;cseq=cmd-seq];last=last-seq。“last-seq”表示单个数据被划分到的多个块的最后顺序号,即单个事务中的最后块的顺序号。此外,后面将描述“n”和“cmd-seq”。
客户端侧收集通信部件202通过客户端侧通信部件204接收从服务器设备300传送的零块。当接收到零块时,客户端侧收集通信部件202确定接收到所有块,并且向浏览器205通知数据接收完成。由此,终止单个事务。
随后,进一步执行分开的事务(步骤S122至S127)。在下面的描述中,将省略或简要描述与上述的数据通信方法的处理相同的处理,并且描述将集中于其间的差异。
在图的步骤S123中,示出了其中在HTTP响应(200OK)中设置“tid=2”和“con=4”的示例。也就是说,可以看出,事务是第二事务(“tid=2”),并且服务器设备300通过其能够对应于客户端设备200的TCP连接数目的上限是4(“con=4”),与上述相同。因此,客户端设备200不必新建立辅连接,并且可以继续使用与上述相同的4个TCP连接(主和辅连接#0、#1、#2和#3)。
2.在客户端设备向服务器设备上载数据的情况下的数据通信方法
图4是图示在客户端设备向服务器设备上载数据的情况下的数据通信方法的顺序图。
浏览器205响应于从用户接收到通过UI 206输入的内容传送请求,而向客户端侧并行通信部件201通知内容传送请求,并且分派要传送到客户端侧分发通信部件203的发送缓冲器(图中未示出)的数据。当从浏览器205接收到内容传送请求时,客户端侧并行通信部件201建立第一TCP连接#0(主连接#0)。客户端侧并行通信部件201生成HTTP PUT请求,其中向其TE头部分配值“mtcp”。客户端侧并行通信部件201通过客户端侧通信部件204使用主连接#0来向服务器设备300传送所生成的HTTP PUT请求(步骤S201)。
在此,在建立主连接#0之后的第一HTTP PUT请求包括Expect头部。Expect头部的值是“100-continue”。
当通过服务器侧通信部件304从客户端侧并行通信部件201接收到HTTP PUT请求时,服务器侧并行通信部件301通过服务器设备300发出唯一的会话id。此外,服务器侧并行通信部件301确定适合于传送HTTP PUT请求所请求上载的数据的TCP连接数目的上限。服务器侧并行通信部件301生成HTTP响应(100-Continue)作为对HTTP PUT请求的响应,其表示会话id、tid和con(TCP连接的数目的上限)。向HTTP响应(100-Continue)的TE头部分配值“mtcp”。服务器侧并行通信部件301通过服务器侧通信部件304使用主连接#0来向客户端设备200传送所生成的HTTP响应(100-Continue)(步骤S202)。
这里,HTTP响应(100-Continue)包括:指定属于相同会话的连接的“session-id”;指定事务的“tid”;表示TCP连接的数目的上限的“con”等。
在图的步骤S202中,示出了其中设置“tid=3”和“con=4”的示例。也就是说,能够看出,该事务是第三事务(“tid=3”),并且服务器设备300通过其能够对应于客户端设备200的TCP连接的数目的上限是4(“con=4”)。
当通过客户端侧通信部件204从服务器侧并行通信部件301接收到HTTP响应(100-Continue)时(步骤S202),客户端侧并行通信部件201检查MTCP会话头部中包括的“con”的值,并且建立第二和随后的TCP连接。客户端侧并行通信部件201通过客户端侧通信部件204分别使用所建立的辅连接#1、#2和#3来并行地向服务器侧并行通信部件301传送HTTP CONNECT请求(步骤S203至S205)。
服务器侧并行通信部件301通过服务器侧通信部件304分别使用辅连接#1、#2和#3接收HTTP CONNECT请求。服务器侧并行通信部件301参考通过所接收的HTTP CONNECT请求所指示的会话id来确定辅连接属于哪个主连接。之后,服务器侧并行通信部件301通过服务器侧通信部件304分别使用辅连接#1、#2和#3并行地向客户端设备200传送HTTP响应(200OK)(步骤S206至S208)。然后,服务器侧并行通信部件301向服务器侧收集通信部件302和服务器侧分发通信部件303通知所建立的辅连接#1、#2和#3。
当通过客户端侧通信部件204接收到相应HTTP响应(200OK)时,客户端侧并行通信部件201向客户端侧收集通信部件202和客户端侧分发通信部件203通知所建立的辅连接#1、#2和#3。至此完成开始并行通信的处理。
当接收到通知时,客户端侧分发通信部件203将由浏览器205分派在发送缓冲器中的数据划分成块,并且分别向块分配顺序号。然后,客户端侧分发通信部件203通过客户端侧通信部件204使用主和辅连接#0、#1、#2和#3向服务器设备300传送被分配顺序号的多个块(步骤S209到S218)。
服务器侧收集通信部件302通过服务器侧通信部件304使用主和辅连接#0、#1、#2和#3接收从客户端设备200传送的相应块。服务器侧收集通信部件302不管使用哪个TCP连接(主和辅连接#0、#1、#2和#3)都临时将所接收的块存储在接收缓冲器中。服务器侧收集通信部件302收集块到某种程度,并且然后向web服务器306提供顺序号连续的块序列作为所接收数据。服务器侧收集通信部件302重复该处理。此外,如果连接没有断开但是存在其中顺序号被省略的部分,则服务器侧收集通信部件302等待被省略块从客户端设备200的到达,同时将在省略之后接收的块存储在接收缓冲器中。
客户端侧分发通信部件203通过客户端侧通信部件204向服务器设备300传送在单个数据被划分成的多个块中的被分配最后顺序号的块(步骤S218)。之后,客户端侧分发通信部件203通过客户端侧通信部件204使用主连接#0向服务器设备300传送零块(步骤S219)。
服务器侧收集通信部件302通过服务器侧通信部件304接收从客户端设备200传送的零块。当接收到零块时,服务器侧收集通信部件302确定接收到所有块,并且向服务器侧通信会话301通知数据接收完成。
当接收到数据接收完成的通知时,服务器侧并行通信部件301生成HTTP响应(200OK),并且通过服务器侧通信部件304使用主连接#0向客户端设备200传送HTTP响应(200OK)(步骤S220)。
当通过客户端侧通信部件204接收到相应HTTP响应(200OK)时,客户端侧并行通信部件201确定完成数据的上载。由此,终止单个事务。
之后,进一步执行单独事务(步骤S221至S227)。在图的步骤S222中,示出了其中在HTTP响应(100-Continue)中设置“tid=4”和“con=4”的示例。也就是说,可以看出,事务是第四事务(“tid=4”),并且服务器设备300通过其能够对应于客户端设备200的TCP连接的数目的上限是4(“con=4”),与上述相同。因此,客户端设备200不必新建立辅连接,并且可以继续使用与上述相同的4个TCP连接(主和辅连接#0、#1、#2和#3)。
3.在数据通信的动作(下载)中增加TCP连接的数目的情况下的数据通信方法
图5是图示在数据通信的动作(下载)中增加TCP连接的数目的情况下的数据通信方法的顺序图。
首先,客户端设备200和服务器设备30执行开始并行通信的处理(步骤S101至S110)。然后,服务器侧分发通信部件303通过服务器侧通信部件304使用任意TCP连接(主和辅连接#0、#1、#2和#3)并行地向客户端设备200传送被分配顺序号的多个块(步骤S111至S114)。
这里,后端服务306确定能够为客户端设备200执行处理的TCP连接的数目的上限增加。在这种情况下,后端服务316向服务器侧并行通信设备301通知TCP连接的数目的上限的增加,并且服务器侧并行通信设备301向服务器侧分发通信部件303通知TCP连接数目的上限的增加。当接收到通知时,服务器侧通信部件303如下重写块头部,该块头部被附加到下一次要传送到客户端设备200的块。如上所述,块头部的语法如下:chunk-size;seq=chunk-seq[;con=n;cseq=cmd-seq][;start=start-seq;tid=t-id]。服务器侧分发通信部件303向“con=n”分配TCP连接的数目的上限(例如“con=5”),其被包括在从服务器侧并行通信部件301发送的通知中。此外,服务器侧分发通信部件303向“cmd-seq”分配值,该值通过递增前一cmd-seq来获得。应注意的是,其第一值被设置为随机值。服务器侧分发通信部件303通过使用任意TCP连接(例如主连接#0)向客户端设备200发送附加了重写的块头部的块(步骤S301)。
这里,“cmd-seq”是表示用于依据连接上限信息的改变而顺序更新的连接数目改变的请求顺序的整数。在根据实施例的并行通信中,由服务器侧分发通信部件303传送到服务器侧通信部件304的数据(多个块)可以通过不同的TCP连接到达客户端侧收集通信部件202。在这种情况下,数据的到达顺序可能改变。例如,假定服务器侧分发通信部件303按照包括被分配“con=1”和“cmd-seq=1”的块头部的块A、包括被分配“con=4”和“cmd-seq=2”的块头部的块B、和包括被分配“con=2”和“cmd-seq=3”的块头部的块C的次序向服务器侧通信部件304传送块。然而,假定客户端侧收集通信部件202按照块A(“con=1”、“cmd-seq=1”)、块C(“con=2”、“cmd-seq=3”)和块B(“con=4”、“cmd-seq=2”)的次序通过客户端侧通信部件204接收块。客户端侧收集通信部件202将包括在多个所接收的块中的cmd-seq的值彼此进行比较,并且确定被设置了最大值的cmd-seq。然后,客户端侧收集通信部件202确定包括被设置了最大值的cmd-seq的块头部表示最新的con。如上所述,通过设置cmd-seq,即使在数据的到达顺序改变时,客户端侧收集通信部件202也能确定TCP连接的数目的最新上限。
客户端侧收集通信部件202通过客户端侧通信部件204从服务器侧分发通信部件303接收块,并且然后检查块头部的cmd-seq的值。客户端侧收集通信部件202确定与先前的值不同的值被设置为cmd-seq,并且然后向客户端侧并行通信部件201通知块头部的con的值,即TCP连接的数目的上限。
客户端侧并行通信部件201从客户端侧收集通信部件202获取TCP连接的数目的上限,并且然后建立新的TCP连接(辅连接#4)。客户端侧并行通信部件201通过客户端侧通信部件204分别使用新建立的辅连接#4并行地向服务器侧并行通信部件301传送HTTP CONNECT请求(步骤S302)。
当通过服务器侧通信部件304使用辅连接#4接收到HTTP CONNECT请求时,服务器侧并行通信部件301通过服务器侧通信部件304使用辅连接#4向客户端设备200传送HTTP响应(200OK)(步骤S303)。然后,服务器侧并行通信部件301向服务器侧收集通信部件302和服务器侧分发通信部件303通知所建立的辅连接#4。
当通过客户端侧通信部件204接收到相应HTTP响应(200OK)时,客户端侧并行通信部件201向客户端侧收集通信部件202和客户端侧分发通信部件203通知所建立的辅连接#4。
当从服务器侧并行通信部件301接收到辅连接#4的建立的通知时,服务器侧分发通信部件303通过服务器侧通信部件304使用任意TCP连接(主和辅连接#0、#1、#2、#3和#4)并行地向客户端设备200传送被分配顺序号的多个块,并且最后通过使用主连接#0向客户端设备200传送零块(步骤S304至S309)。
4.在数据通信的动作(上载)中增加TCP连接的数目的情况下的数据通信方法
图6是图示在数据通信的动作(上载)中增加TCP连接的数目的情况下的数据通信方法的顺序图。
首先,客户端设备200和服务器设备30执行开始并行通信的处理(步骤S201至S208)。然后,客户端侧分发通信部件203通过客户端侧通信部件204使用任意TCP连接(主和辅连接#0、#1、#2和#3)并行地向服务器设备300传送被分配顺序号的多个块(步骤S209至S212)。
这里,服务器侧并行通信部件301确定能够在服务器设备300上为客户端设备200执行处理的TCP连接数目的上限增加。在这种情况下,服务器侧并行通信部件301生成HTTP响应(100-Continue),其具有其中向con分配TCP连接数目的新上限的MTCP会话头部。服务器侧并行通信部件301通过服务器侧通信部件304使用主连接#0向客户端设备200传送所生成的HTTP响应(100-Continue)(步骤S401)。
当通过客户端侧通信部件204从服务器侧并行通信部件301接收到HTTP响应(100-Continue)(步骤S401)时,客户端侧并行通信部件201检查包括在MTCP会话头部中的“con”的值。也就是说,客户端侧并行通信部件201检查与服务器设备300相兼容的TCP连接的数目的上限,并且然后建立新的TCP连接(在该示例中,辅连接#4)。客户端侧并行通信部件201通过客户端侧通信部件204分别使用新建立的辅连接#4并行地向服务器侧并行通信部件301传送HTTP CONNECT请求(步骤S402)。
服务器侧并行通信部件301通过服务器侧通信部件304使用辅连接#4接收HTTP CONNECT请求。之后,服务器侧并行通信部件301通过服务器侧通信部件304使用辅连接#4并行向客户端设备200传送HTTP响应(200OK)(步骤S403)。然后,服务器侧并行通信部件301向服务器侧收集通信部件302和服务器侧分发通信部件303通知所新建立的辅连接#4。
当通过客户端侧通信部件204接收到相应HTTP响应(200OK)时,客户端侧并行通信部件201向客户端侧收集通信部件202和客户端侧分发通信部件203通知所建立的辅连接#4。
当从客户端侧并行通信部件201接收到辅连接#4的建立的通知时,客户端侧分发通信部件203通过服务器侧通信部件304使用任意TCP连接(主和辅连接#0、#1、#2、#3和#4)并行地向客户端设备200传送被分配顺序号的多个块,并且最后通过客户端侧通信部件204使用主连接#0向服务器设备300传送零块(步骤S404至S409)。
当通过服务器侧通信部件304接收到从客户端设备200传送的零块,服务器侧收集通信部件302确定接收到所有块,并且向服务器侧并行通信部件301通知数据接收完成。当接收到数据接收完成的通知时,服务器侧并行通信部件301生成HTTP响应(200OK),并且通过服务器侧通信部件使用主连接#0向客户端设备200传送HTTP响应(200OK)(步骤S410)。
5.在数据通信的动作中减少TCP连接的数目的情况下的数据通信方法
图7是图示在数据通信的动作中减少TCP连接的数目的情况下的数据通信方法的顺序图。
在此将描述在数据通信的动作(下载)中减少TCP连接的数目的情况下的数据通信方法。
首先,客户端设备200和服务器设备30执行开始并行通信的处理(步骤S101至S110)。然后,服务器侧分发通信部件303通过服务器侧通信部件304使用任意TCP连接(主和辅连接#0、#1、#2和#3)并行地向客户端设备200传送被分配顺序号的多个块(步骤S111至S114)。
这里,服务器侧并行通信设备301确定在服务器设备300侧上能够为客户端设备200执行处理的TCP连接数目减少。在这种情况下,为了减少TCP连接的数目,必须停止使用要减少的TCP连接的数据通信。否则,发生数据丢失。为了防止发生数据丢失,通过下面的方法来减少TCP连接的数目。
服务器侧并行通信部件301向服务器侧分发通信部件303发出减少TCP连接的数目的通知。当接收到通知时,服务器侧分发通信部件303通过服务器侧通信部件304使用要减少的辅连接向客户端设备200传送零块。这里,零块的形式例如如下:“0;con=n;cseq=cmd-seq”。
该示例示出下面的情况:当目前使用四个TCP连接(包括主连接)时,通过断开它们中的两个辅连接来设置两个TCP连接。服务器侧分发通信部件303任意地选择两个辅连接(例如辅连接#2和#3)作为断开连接目标。服务器侧分发通信部件303通过服务器侧通信部件304使用所选择的辅连接#2和#3向客户端设备200传送被分配con=2的零块(步骤S501、S502)。
此外,在通过主连接执行下载/上载之后传递正常块。然而,即使在完成下载/上载之后,也可以在任意时刻从服务器设备300向客户端设备200传送零块。
当通过服务器侧通信部件304向客户端设备200传送零块时,服务器侧分发通信部件303停止使用作为断开连接目标的辅连接#2和#3传输新的块。然后,服务器侧分发通信部件303等待客户端设备200断开辅连接#2和#3。然而,由于用于PUT的块可能从客户端侧分发通信部件203到达服务器侧收集通信部件302,服务器侧收集通信部件302处于对块接收的备用,直到断开辅连接#2和#3。原因在于考虑下面的情况:客户端设备200在与服务器侧分发通信部件303传送零块的时间基本相同的时间上开始上载处理。也就是说,原因在于,在这样的情况下,在零块到达客户端设备200之前,客户端侧分发通信部件203可能通过使用辅连接#2和#3向客户端侧通信部件204传送用于上载的块。
此后,服务器侧分发通信部件303通过服务器侧通信部件304使用除断开的辅连接#2和#3外的任意TCP连接(主和辅连接#0和#1)并行地向客户端设备200传送多个块(步骤S503和S504)。之后,服务器侧分发通信部件303通过服务器侧通信部件304使用主连接#0向客户端设备200传送零块(步骤S505)。
至此已给出了在数据通信的动作(下载)中减少TCP连接的数目的情况下的数据通信方法的描述,但是在数据通信的动作(上载)中,可执行如下的处理。也就是说,如果正在传送用于上载的块,则客户端侧分发通信部件203响应于接收到零块而停止传送新的块。然后,客户端侧分发通信部件203检查所传送的块到达服务器设备300,并且断开作为断开连接目标的连接。此外,客户端侧分发通信部件203检查所传送的块到达服务器设备300的技术可能以存在诸如TCP的可靠传输为前提。
根据实施例,通过动态增加或减少辅连接的数目,能够控制吞吐量。例如在以下情况中,对辅连接的数目的动态控制是有利的。
假定路径的链路速度是L并且单个TCP连接的吞吐量是T。在该假定下,当建立n个连接(其中n是满足条件nT<L的最大自然数)时,可能获得最大吞吐量。应注意,尽管将n设置为等于或大于上述条件,但是由于链路速度L的限制而发生错误,并且因此难以获得该吞吐量。
此外,例如,在类似流送可以确定必要吞吐量(其用Q表示并且满足Q<L)的情况下,建立数目等于或大于该吞吐量所必要的数目的连接是无效的。在这种情况下,可以建立m个TCP连接,其中m是满足条件mT>Q的最小数)。
此外,在单个服务器设备300和多个客户端设备200几乎同时执行通信的情况下,由于服务器设备300的处理能力的限制,每个客户端设备200可以被提供的吞吐量是有限的。当客户端设备200的数目增加时,通过降低到连接的客户端设备200的吞吐量,可能使得它们等于到新客户端设备200的吞吐量。由此,可能在多个客户端设备200中同等地执行服务。
6.在客户端设备向服务器设备传送GET请求并且在从服务器设备获取响应之前进一步传送PUT请求的情况下的数据通信方法(流水线技术)。
首先,将描述现有技术中的HTTP流水线技术。HTTP流水线技术是其中客户端传送HTTP请求并且在与先前的HTTP请求对应的响应到达之前发送接下来的HTTP请求的技术。当服务器兼容流水线技术时,接下来的HTTP在服务器侧排队,并且随后被处理,并且然后返回HTTP响应。
如上所述,HTTP流水线技术能够在不等待响应的情况下发送下一请求,但是响应的顺序与请求的顺序相同。原因在于难以同时处理在单个TCP中的不同请求的信息条。由此,出现问题,原因在于:例如,如果处理单个请求花费时间,则对每一个原本花费短处理时间的其它请求进行响应也花费时间。
图8是图示在客户端设备向服务器设备传送GET请求并且在从服务器设备获取响应之前进一步传送PUT请求的情况下的数据通信方法(流水线技术)的顺序图。
在图中,每个实线箭头表示通过客户端侧通信部件204和服务器侧通信部件304在客户端侧并行通信部件201和服务器侧并行通信部件301之间的通信(下载)。图中的每个点划线箭头表示通过客户端侧通信部件204和服务器侧通信部件304在客户端侧收集通信部件202和服务器侧分发通信部件303之间的通信(下载)。每个点线(dotted-line)箭头表示通过客户端侧通信部件204和服务器侧通信部件304在客户端侧并行通信部件201和服务器侧并行通信部件301之间的通信(上载)。图中的每个划线(dashed-line)箭头表示通过客户端侧通信部件204和服务器侧通信部件304在客户端侧分发通信部件203和服务器侧收集通信部件302之间的通信(上载)。
首先,客户端侧并行通信201通过客户端侧通信部件204向服务器设备300传送HTTP GET请求(步骤S601)。客户端侧并行通信部件201在从服务器设备300获取对HTTP GET请求的响应之前通过客户端侧通信部件204向服务器设备300传送HTTP PUT请求(步骤S602)。
在该示例的步骤S603中,示出了在HTTP响应(200OK)中设置了“tid=5”的示例。也就是说,可以看出,事务是第五事务(“tid=5”)。此外,在步骤S607、S608和S617-S622中,在下载数据的每个块中设置了“tid=5”。
另一方面,在该示例的步骤S612中,示出了在HTTP响应(100-Continue)中设置了“tid=6”的示例。也就是说,可以看出,事务是第六事务(“tid=6”)。此外,在步骤S613-S615中,在上载数据的每个块中设置了“tid=6”。
在此,关注于所传递的块,首先,在步骤S607和S608中,对下载目标数据的一部分的块(tid=5)进行下载。接下来,在步骤S613至S616中,对上载目标数据的所有块(tid=6)进行上载。最后,在步骤S617至S623中,对下载目标数据的剩余块(tid=5)进行下载。在实施例中,不必按照以下次序执行数据通信:下载属于下载目标数据的所有块,然后上载属于上载目标数据的所有块。
在实施例中,向块分别分配事务ID(tid)。由此,当接收侧(在上载的情况下为服务器设备300,在下载的情况下为客户端设备200)参考事务ID,能够不管数据通信的顺序如何而恢复用于具有相同事务ID(tid)的每个块的数据。例如,当下载多条数据时,客户端设备200可能按照一个数据被划分到的数据条与另一个数据被划分到的数据条被混合的顺序接收作为一个数据被划分到的数据条的块以及另一个数据被划分到的数据条的块。即使在该情况下,客户端设备200也能够参考用于指定每条数据的tid恢复用于具有相同tid的每个块的多条数据。
在实施例中,在用流水线技术传送HTTP请求之后,事务ID(tid)指示连接用于哪个事务(哪个请求)。由此,在现有技术中,应该按照请求的顺序返回HTTP响应的头部,但是在实施例中,如果必要能够改变数据的传输顺序或并行地传送和接收多个内容。
7.在客户端设备向服务器设备传送GET请求并且在从服务器设备获取响应之前进一步传送单独的GET请求的情况下的数据通信方法(流水线技术)。
图9是图示在客户端设备向服务器设备传送GET请求并且在从服务器设备获取响应之前进一步传送单独的GET请求的情况下的数据通信方法(流水线技术)的顺序图。
在图中,每个实线箭头表示客户端设备200和服务器设备300之间的通信(下载某个数据)。图中的每个双点的划线(chain-double-dashed-line)箭头表示客户端设备200和服务器设备300之间的通信(下载某个数据)。图中的每个点划线箭头表示建立辅连接的处理。
首先,客户端侧并行通信201通过客户端侧通信部件204向服务器设备300传送第一HTTP GET请求(称为HTTP GET请求1)(步骤S701)。客户端侧并行通信部件201在从服务器设备300获取对HTTP GET请求1的响应之前通过客户端侧通信部件204向服务器设备300传送第二HTTP GET请求(称为HTTP GET请求2)(步骤S702)。
在该示例的步骤S703中,示出了在HTTP响应(200OK)中设置了“tid=1”的示例。也就是说,可以看出,事务是第一事务(“tid=1”)。此外,在步骤S716至S720中,在下载数据的每个块中设置了“tid=1”。
另一方面,在该示例的步骤S710中,示出了在HTTP响应(200OK)中设置了“tid=2”的示例。也就是说,可以看出,事务是第二事务(“tid=2”)。此外,在步骤S711至S714中,在下载数据的每个块中设置了“tid=2”。
以HTTP GET请求的顺序返回HTTP响应(200OK)。因此,客户端侧并行通信部件201能够参考HTTP响应(200OK)的头部来验证哪个事务ID被分配给其自己发出的HTTP GET请求。
在此,关注于通信的块,首先,在步骤S711至S715中,下载由HTTP GET请求2指定的下载目标数据的块(tid=2)。接下来,在步骤S716至S720中,下载由HTTP GET请求1指定的下载目标数据的块(tid=1)。在实施例中,不必按照以下次序执行数据通信:下载属于由HTTP GET请求1指定的下载目标数据的块,然后下载属于由HTTP GET请求2指定的下载目标数据的块。在实施例中,向块分别分配事务ID(tid)。因而,当作为接收侧的客户端设备200参考事务ID(tid)时,能够不管数据通信的顺序如何而恢复用于具有相同事务ID的每个块的数据。
更具体地,将关注于使用辅连接#1的通信,给出描述。首先,客户端侧收集通信部件202通过客户端侧通信部件204接收seq:1a26start:1a25tid:2的块(步骤S712)。客户端侧收集通信部件202确定所述块是HTTP GET请求2的第二块。之后,客户端侧收集通信部件202通过客户端侧通信部件204接收seq:1a22start:1a21tid:1的块(步骤S717)。客户端侧收集通信部件202确定通过辅连接#1对与HTTP GET请求2相关的数据(块)的接收刚刚完成,并且当前块是HTTP GET请求1的第二块。
在实施例中,为了指示发送的数据对应于哪个请求,将tid额外地写入在块中,所述tid表示发送数据的连接用于哪个事务。由此,在用流水线技术传送HTTP请求之后,事务ID(tid)指示连接用于哪个事务(哪个请求),由此接收侧设备能够不管数据通信的顺序如何而恢复数据。以此方式,如果必要传输侧设备能够改变数据传输的顺序或并行地发送多个内容。
8.从TCP连接的无意连接断开中恢复数据的方法(下载时)
接下来,将给出关于多个辅连接中的一些由于诸如通信故障的另一侧通信装置的情形而无意地断开连接的情况的描述。在这样的情况下,能够以以下方式维护数据的完整。
首先,将描述服务器设备300的处理。当一个或多个辅连接断开时,服务器侧分发通信部件303通过服务器侧通信部件304挑选其它连接向客户端设备200重新传送在使用断开的辅连接的传输期间存在的块。另一方面,客户端侧收集通信部件202参考通过客户端侧通信部件204接收的块的“chunk-seq”。服务器侧分发通信部件303可以确定块传送失败并且重新传送该同一块。在这种情况下,如果双向传输实际上是成功的,则客户端侧收集通信部件202可以冗余地获取该同一块。然而,客户端侧收集通信部件202能够通过参考每个所获取的块的“chunk-seq”来识别冗余的块,因而能够忽略被冗余获取的块中的一个。
接下来,将描述客户端设备200的处理。当一个或多个辅连接断开时,客户端侧并行通信部件201将会话id指定为与第一会话id相同,并且通过使用HTTP CONNECT重新建立辅连接,除非其超过能够被允许建立的连接的数目的上限。当在使用断开的连接的传输期间存在块时,期望通过使用包括由服务器设备300新建立的辅连接的连接中的任何一个重新传送块。如上所述,客户端侧收集通信部件202能够通过参考每个块的“chunk-seq”来检测冗余块。在没有传输的情况中,可以通过重新发出HTTP GET请求并且通过Range(范围)头部仅仅指定丢失块的位置来解决上述问题。此外,通过上述的流水线技术处理,即使在原始HTTP GET请求结束之前,客户端侧并行通信部件201也能够通过客户端侧通信部件204并行地传送补充HTTP GET请求。
9.从TCP连接的无意连接断开来恢复数据的方法(上载时)
首先,将描述客户端设备200的处理。当一个或多个辅连接断开时,客户端侧并行通信部件201将会话id指定为与第一会话id相同,并且通过使用HTTP CONNECT重新建立辅连接,除非其超过能够被允许建立的连接的数目的上限。当在使用断开的连接的传输期间存在块时,客户端侧分发通信部件203通过客户端侧通信设备204使用包括新建立的辅连接的连接中的任何一个来重新传送块。服务器侧收集通信部件302能够通过参考每个获取的块的“chunk-seq”来识别冗余块,因而能够忽略被冗余地获取的块中的一个。
接下来,将描述服务器设备300的处理。即使当一个或多个辅连接断开时,服务器侧收集通信部件302也通过使用剩余连接而继续如同它通过服务器侧通信部件304一样接收数据。当在使用断开的连接的传输期间存在块时,期望通过客户端设备200使用剩余连接重新传送块。服务器侧收集通信部件302能够通过参考每个获取的块的“chunk-seq”来识别冗余块,因而能够忽略被冗余地获取的块中的一个。当在接收零块时存在数据(块)丢失时,服务器侧收集通信部件302能够通过服务器侧通信部件304向客户端设备200传送HTTP错误。
客户端设备的硬件配置
接下来,将描述客户端设备200和服务器设备300的硬件配置。
图10是图示客户端设备的硬件配置的框图。
在客户端设备200中,CPU(中央处理单元)612通过系统总线613连接到输入操作部件601、客户端侧通信部件204、存储部件604、解码部件605、显示部件606、介质接口部件608、ROM(只读存储器)610、和RAM(随机存取存储器)611。
输入操作部分601具有各种键。用户通过使用输入操作部件601来输入各种命令或数据。通过系统总线613将由用户从输入操作部件601输入的各种命令提供给CPU 612。
客户端侧通信部件204处理与全局网络101的连接。
存储部件604被形成为HDD、SSD等。将客户端侧通信部件204通过网络101下载的内容数据存储在存储部件604中。解码部件605对从存储部件604读取的内容数据进行解码,并且恢复数字视频数据和数字音频数据。通过系统总线613将所恢复的数字视频数据提供给显示部件606,并且通过系统总线613将数字音频数据提供给扬声器部件607。
显示部件606包括例如具有诸如LCD(液晶显示器)的显示屏的显示单元、驱动显示单元的显示控制电路等。显示部件606显示从用户输入的指令、数据的确认、各种状态等。
介质接口部件608能够配置有诸如光盘的可移动介质614,并且能够将内容数据等记录在可移动介质614中。可移动介质614的示例包括可记录DVD、可重写DVD、蓝光盘等。
ROM 610是其中永久地存储用于由客户端设备200执行软件处理的程序、数据等的只读存储器。此外,可以将程序存储在存储部件604中。
RAM 611是可写易失性存储器,其用于加载由CPU 612执行的程序和代码、或写入程序的工作数据。
CPU 612共同地执行客户端设备200的各部件的控制、并控制在各部件之间的数据交换。CPU 612从ROM 610向RAM 611加载通过客户端设备200执行软件处理所需要的程序,并且通过其分析执行程序。
如上所述,通过使用典型的计算机硬件来配置客户端设备200。此外,存储在ROM 610中的程序使得客户端设备200的计算机硬件作用为图2中所示的相应模块。
服务器设备的硬件配置
图11是图示服务器设备的硬件配置的框图。
在服务器设备300中,CPU(中央处理单元)512通过系统总线513连接到输入操作部件501、服务器侧通信部件304、存储部件504、显示部件506、ROM(只读存储器)510、和RAM(随机存取存储器)511。
输入操作部件501具有各种键。服务器管理员通过使用输入操作部件501来输入各种命令或数据。通过系统总线513将由服务器管理员从输入操作部件501输入的各种命令提供给CPU 512。
服务器侧通信部件304(网络连接部件)处理与全局网络101的连接。
存储部件504被形成为HDD、SSD等。将服务器侧通信部件304通过网络101上载的内容数据存储在存储部件504中。
显示部件506包括例如具有诸如LCD(液晶显示器)的显示屏的显示单元、驱动显示单元的显示控制电路等。显示部件506显示从用户输入的指令、数据的确认、各种状态等。
介质接口部件508能够配置有诸如光盘的可移动介质614。可移动介质614的示例包括可记录DVD、可重写DVD、蓝光盘等。
ROM 510是其中永久地存储用于由服务器设备300执行软件处理的程序、数据等的只读存储器。此外,可以将程序存储在存储部件504中。
RAM 511是可写易失性存储器,其用于加载由CPU 512执行的程序和代码、或写入程序的工作数据。
CPU 512共同地执行服务器设备300的各部件的控制、并控制在各部件之间的数据交换。CPU 512从ROM 510向RAM 511加载通过服务器设备300执行软件处理所需要的程序,并且通过其分析执行程序。
存储在ROM 510中的程序使得服务器设备300的计算机硬件作用为图2中所示的相应模块。
本公开包含与在2010年10月27日向日本专利局提交的日本优先权专利申请JP 2010-240691中公开的主题相关的主题,其整个内容由此通过引用被合并于此。
本领域技术人员应理解,在所附权利要求或其等同物的范围内的情况下,可以基于设计需求和其它因素进行各种修改、组合、子组合和替代。
Claims (6)
1.一种在第一信息处理设备和第二信息处理设备之间建立多个TCP(传输控制协议)连接并且通过多个所建立的TCP连接来传递为每个规定单元划分的每条数据的数据通信方法,
其中,所述第一信息处理设备通过向所述第二信息处理设备通知连接上限信息、并且通过改变要通知的所述连接上限信息来动态地改变与所述第二信息处理设备的TCP连接的数目,所述连接上限信息表示要与所述第二信息处理设备建立的TCP连接的数目的上限。
2.根据权利要求1所述的数据通信方法,
其中,所述第一信息处理设备依据所述连接上限信息的改变而顺序地更新命令顺序信息,并且向所述第二信息处理设备传送所述信息,
其中,所述第二信息处理设备基于所接收的命令顺序信息识别出来自所述第一信息处理设备的最近的连接上限信息。
3.根据权利要求2所述的数据通信方法,
其中,所述第一信息处理设备向每条已划分数据的头部添加所述连接上限信息和所述命令顺序信息,并且向所述第二信息处理设备传送所述信息。
4.根据权利要求3所述的数据通信方法,
其中,所述第二信息处理设备向所述第一信息处理设备传送包括用于指定数据的数据指定信息的传送请求,以及
其中,所述第一信息处理设备将在所接收的传送请求中包括的数据指定信息所指定的数据划分成用于每个规定单元的条,将所述数据指定信息添加到每条已划分数据的头部,并且将所述数据传送到所述第二信息处理设备。
5.根据权利要求4所述的数据通信方法,
其中,所述第一信息处理设备进一步将用于识别没有被划分的数据的上下文的上下文识别信息添加到每条已划分数据的头部。
6.一种信息处理设备,包括:
能够连接到网络的网络连接部件;以及
改变装置,当通过所述网络连接部件建立与不同信息处理的多个TCP(传输控制协议)连接、并且通过多个所建立的TCP连接传递为每个规定单元划分的每条数据时,所述改变装置通过向所述不同信息处理通知连接上限信息、并且通过改变要通知的所述连接上限信息来动态地改变与所述不同信息处理的TCP连接的数目,所述连接上限信息表示要与不同信息处理建立的TCP连接的数目的上限。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010240691A JP5640649B2 (ja) | 2010-10-27 | 2010-10-27 | データ通信方法及び情報処理装置 |
JP2010-240691 | 2010-10-27 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN102457573A true CN102457573A (zh) | 2012-05-16 |
Family
ID=45997917
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2011103195811A Pending CN102457573A (zh) | 2010-10-27 | 2011-10-20 | 数据通信方法和信息处理设备 |
Country Status (3)
Country | Link |
---|---|
US (1) | US8898311B2 (zh) |
JP (1) | JP5640649B2 (zh) |
CN (1) | CN102457573A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102907071A (zh) * | 2012-07-26 | 2013-01-30 | 华为技术有限公司 | 一种数据传输方法、移动终端和代理服务器 |
CN102970356A (zh) * | 2012-11-08 | 2013-03-13 | 百度在线网络技术(北京)有限公司 | 云端服务器和客户端的通信方法、系统和装置 |
CN114697293A (zh) * | 2022-03-30 | 2022-07-01 | 西安北方华创微电子装备有限公司 | 一种数据传输方法、下位机和控制器 |
Families Citing this family (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5758723B2 (ja) * | 2011-07-04 | 2015-08-05 | 株式会社日立国際電気 | 画像転送装置 |
US9258272B1 (en) | 2011-10-21 | 2016-02-09 | Juniper Networks, Inc. | Stateless deterministic network address translation |
US9178846B1 (en) | 2011-11-04 | 2015-11-03 | Juniper Networks, Inc. | Deterministic network address and port translation |
US20130268584A1 (en) * | 2012-04-08 | 2013-10-10 | Arun Raghavendra Desai | Methods and apparatus for publishing and subscribing electronic documents using intermediate rendezvous servers |
US8891540B2 (en) | 2012-05-14 | 2014-11-18 | Juniper Networks, Inc. | Inline network address translation within a mobile gateway router |
WO2014049943A1 (ja) * | 2012-09-27 | 2014-04-03 | 日本電気株式会社 | マルチメディアデータ通信装置、方法、プログラムおよび有効データ増加率算出装置 |
JP2014078895A (ja) * | 2012-10-11 | 2014-05-01 | Toshiba Corp | サーバ装置及び通信システム |
EP2910001A4 (en) * | 2012-10-18 | 2016-04-20 | Giraffic Technologies Ltd | OVERLOAD CONTROL METHOD FOR DYNAMICALLY MAXIMIZING A COMMUNICATION CONNECTION THROUGHPUT |
US9769239B2 (en) * | 2014-09-30 | 2017-09-19 | Qualcomm Incorporated | Systems and methods for user agent signaling request acceleration by transport accelerator |
JP6541322B2 (ja) | 2014-10-07 | 2019-07-10 | キヤノン株式会社 | 画像読取装置、画像読取装置の制御方法、及びプログラム |
JP6444125B2 (ja) | 2014-10-07 | 2018-12-26 | キヤノン株式会社 | 情報処理装置、情報処理装置の制御方法、及びプログラム |
JP6548445B2 (ja) | 2015-05-08 | 2019-07-24 | キヤノン株式会社 | 通信装置、通信方法及びプログラム |
US10129207B1 (en) | 2015-07-20 | 2018-11-13 | Juniper Networks, Inc. | Network address translation within network device having multiple service units |
US10142262B2 (en) * | 2016-05-31 | 2018-11-27 | Anchorfree Inc. | System and method for improving an aggregated throughput of simultaneous connections |
US10469446B1 (en) | 2016-09-27 | 2019-11-05 | Juniper Networks, Inc. | Subscriber-aware network address translation |
EP3643032B1 (en) * | 2017-06-20 | 2021-04-07 | Telefonaktiebolaget LM Ericsson (PUBL) | Apparatuses and methods for live uplink adaptive streaming |
JP6728314B2 (ja) * | 2018-11-28 | 2020-07-22 | キヤノン株式会社 | 情報処理装置、情報処理装置の制御方法、及びプログラム |
US20200296462A1 (en) | 2019-03-11 | 2020-09-17 | Wci One, Llc | Media content presentation |
US20200296316A1 (en) | 2019-03-11 | 2020-09-17 | Quibi Holdings, LLC | Media content presentation |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030208600A1 (en) * | 2000-03-24 | 2003-11-06 | Cousins Robert E. | System and method for managing persistent connections in HTTP |
US20080130658A1 (en) * | 2005-07-20 | 2008-06-05 | Jacob Chakareski | System and method for low-delay, interactive communication using multiple tcp connections and scalable coding |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11242640A (ja) * | 1998-02-25 | 1999-09-07 | Kdd Corp | ファイル転送方法 |
JP2000322309A (ja) * | 1999-05-13 | 2000-11-24 | Kdd Corp | ファイル伝送装置 |
US20040131059A1 (en) * | 2002-09-19 | 2004-07-08 | Ram Ayyakad | Single-pass packet scan |
JP2004206172A (ja) * | 2002-12-20 | 2004-07-22 | Sanyo Electric Co Ltd | 通信制御方法および装置 |
JP2005057482A (ja) | 2003-08-04 | 2005-03-03 | Fujitsu Fip Corp | データ転送方法、データ転送用プログラムおよび記録媒体 |
JP2006195749A (ja) * | 2005-01-13 | 2006-07-27 | Sanyo Electric Co Ltd | 情報処理システム、サーバ装置及びクライアント端末装置 |
JP4714074B2 (ja) * | 2006-05-02 | 2011-06-29 | 日本放送協会 | 伝送装置、送信装置及び受信装置 |
US9432433B2 (en) * | 2006-06-09 | 2016-08-30 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
US20080291833A1 (en) * | 2007-05-25 | 2008-11-27 | Gustav Gerald Vos | Method for buffer control for network device |
-
2010
- 2010-10-27 JP JP2010240691A patent/JP5640649B2/ja not_active Expired - Fee Related
-
2011
- 2011-10-20 US US13/277,855 patent/US8898311B2/en not_active Expired - Fee Related
- 2011-10-20 CN CN2011103195811A patent/CN102457573A/zh active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030208600A1 (en) * | 2000-03-24 | 2003-11-06 | Cousins Robert E. | System and method for managing persistent connections in HTTP |
US20080130658A1 (en) * | 2005-07-20 | 2008-06-05 | Jacob Chakareski | System and method for low-delay, interactive communication using multiple tcp connections and scalable coding |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102907071A (zh) * | 2012-07-26 | 2013-01-30 | 华为技术有限公司 | 一种数据传输方法、移动终端和代理服务器 |
WO2014015503A1 (zh) * | 2012-07-26 | 2014-01-30 | 华为技术有限公司 | 一种数据传输方法、移动终端和代理服务器 |
CN102907071B (zh) * | 2012-07-26 | 2015-04-29 | 华为技术有限公司 | 一种数据传输方法、移动终端和代理服务器 |
CN102970356A (zh) * | 2012-11-08 | 2013-03-13 | 百度在线网络技术(北京)有限公司 | 云端服务器和客户端的通信方法、系统和装置 |
CN114697293A (zh) * | 2022-03-30 | 2022-07-01 | 西安北方华创微电子装备有限公司 | 一种数据传输方法、下位机和控制器 |
Also Published As
Publication number | Publication date |
---|---|
US8898311B2 (en) | 2014-11-25 |
US20120110194A1 (en) | 2012-05-03 |
JP5640649B2 (ja) | 2014-12-17 |
JP2012095098A (ja) | 2012-05-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102457573A (zh) | 数据通信方法和信息处理设备 | |
CN110661871B (zh) | 一种数据传输方法及mqtt服务器 | |
CN112685248B (zh) | 智能网卡监控日志获取方法、装置、电子设备及存储介质 | |
CN102347947A (zh) | 一种流媒体适配器、流媒体网络交互的系统及方法 | |
US10425253B2 (en) | Inband data gathering with dynamic intermediary route selections | |
JP2008271097A (ja) | 通信装置およびクライアント装置 | |
CN110808948A (zh) | 远程过程调用方法、装置及系统 | |
CN110493122A (zh) | 一种会话信息的同步方法、装置、计算设备及存储介质 | |
CN103281362A (zh) | 一种文件传输协议 | |
CN110875914A (zh) | 一种基于共享会话链路传输消息的方法及装置 | |
CN102065143B (zh) | 基于http的通信方法及系统、http服务器、http客户端 | |
CN101986659B (zh) | 数据实时传输的方法及系统 | |
CN103297641A (zh) | 图像形成装置以及图像形成系统 | |
JP5961471B2 (ja) | 複数の情報システムおける出力比較方法 | |
EP1220513A2 (en) | Method and apparatus for handling services by a proxy | |
WO2021201870A1 (en) | Configuring a publisher device of a publish-subscribe system | |
JP2000293452A (ja) | データ中継装置、データ通信システム、データ通信方法及び記録媒体 | |
CN112448952B (zh) | 解决远程接收并存储智能设备参数的方法及装置 | |
CN110764932A (zh) | 数据处理方法、系统、介质和计算设备 | |
CN102143196B (zh) | 客户端通信方法、装置和系统 | |
CN116016089A (zh) | 冶金设备数据处理方法、装置及系统 | |
WO2006122182A2 (en) | Systems and methods for determining user preferences and/or facsimile device capabilities before call initiation | |
CN111028578A (zh) | 一种面向职业资格教育的远程共享系统 | |
Shan et al. | IoT Communication Based on MQTT and OneNET Cloud Platform in Big Data Environment | |
CN117938895A (zh) | 油气管网监控系统实时数据过网传输系统和方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20120516 |