CN101278529B - 通信装置 - Google Patents

通信装置 Download PDF

Info

Publication number
CN101278529B
CN101278529B CN2006800368286A CN200680036828A CN101278529B CN 101278529 B CN101278529 B CN 101278529B CN 2006800368286 A CN2006800368286 A CN 2006800368286A CN 200680036828 A CN200680036828 A CN 200680036828A CN 101278529 B CN101278529 B CN 101278529B
Authority
CN
China
Prior art keywords
bag
data
communicator
ack
packet
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.)
Expired - Fee Related
Application number
CN2006800368286A
Other languages
English (en)
Other versions
CN101278529A (zh
Inventor
仓田洋
冈崎芳纪
辻敦宏
高垣景一
松下阳介
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Holdings Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Publication of CN101278529A publication Critical patent/CN101278529A/zh
Application granted granted Critical
Publication of CN101278529B publication Critical patent/CN101278529B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1832Details of sliding window management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/19Flow control; Congestion control at layers above the network layer
    • H04L47/193Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263Rate modification at the source after receiving feedback
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/28Flow control; Congestion control in relation to timing considerations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1887Scheduling and prioritising arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

能够在对应本身的接收能力而自发地控制数据的发送通信量的同时,提供减轻了该控制处理负担的通信装置。其具备接收数据的通信部(35);生成针对由通信部(35)接收的数据的、表示对发送方装置(38)的应答内容的ACK包,并且发送到发送方装置(38)的ACK生成部(45);无论通信部(35)的数据接收的结果如何,都生成对发送方装置(38)请求数据发送的窗口更新通知包,并发送到发送方装置(38)的窗口更新通知生成部(46)。

Description

通信装置
技术领域
本发明涉及一种通信装置,尤其涉及通过互联网协议(InternetProtocol:以下称做IP)网络并使用传输控制协议(Transmission ControlProtocol:以下称做TCP)来进行数据传送的通信装置。
背景技术
图1是在TCP中数据传送过程的序列图。
在TCP的数据传送中,数据是以被称为“包”的单位被收发的。而且,一个包的大小是根据预先互相传递的包的最大大小信息(MaximumSegment Size:最大段长度,以下称做MSS)来决定的。对于发送方装置所传送的包来说,此包到达接收方装置是指,接收方装置传送肯定应答包(Acknowledgement Packet:以下称做ACK或者ACK包),并且通过发送方装置进行接收而被确认。另外,肯定应答包也叫做确认应答包。在图1的例子中,数据包用实线来表示,ACK包用虚线来表示。并且,例如在数据包中记载的P21(Seq=10)表示正在发送序列号码10的包。还有,例如,在ACK包中记载的P11(Ack=10,Win=4)表示ACK号码10及窗口大小4的包。另外,为了简化说明,将数据包的大小作为1来进行说明。
其次,进行窗口大小的说明。窗口大小是指,发送方装置在没有得到ACK包的情况下,就能够向接收方装置连续传送数据的数据量。一般情况下,此窗口大小表示对接收方装置所接收的数据能够进行保持的最大容量的最大限度(以下称做RWIN_MAX),且按照网络的集中状态等通过发送方装置来进行增减。在理想的状态下无网络集中,并且为窗口大小稳定于RWIN_MAX的值的状态。
在图1的例子中,接收方装置通过ACK包P11发出ACK号码是10 和窗口大小是4的通知。因此,发送方装置可以不用等待对应于四个数据包的ACK包,而将序列号码10至13的数据包P21、P22、P23、P24进行发送。
接收方装置具有用于暂时保持接收方装置所接收的数据的接收缓存,一般能够确保RWIN_MAX容量的数据。而且,此接收缓存的可用空间由于来自发送方装置的包接收而减少,通过向应用程序提交接收数据而增加。还有,在接收缓存的可用空间增加时,接收方装置具有:将被称为窗口更新通知包的包进行发送、且将接收缓存的可用空间已经增加的信息通知给发送方装置的功能。
图1的例子中,在发送数据包P21、P22、P23、P24之后,ACK包P12、P13里的窗口大小减小且最终变为0。即,已接收的数据包P21、P22、P23、P24依然被保持在接收缓存中,而且是尚未向应用程序提交接收数据的状态。此后,在向应用程序进行接收数据的提交的情况下,接收方装置发送窗口更新通知包P14,并将窗口大小只有四个空闲的信息通知给发送方装置。发送方装置在接收窗口更新通知包P14的情况下,重新开始后续的数据包P25、P26、P27、P28的发送。
而且,将接收方装置发送ACK包P11的时刻和接收从发送方装置所发送的数据包P21的时刻之间的差额,称为应答延迟时间(Round TripTime:以下称做RTT)。通过较大的RTT的网络进行数据传送时,发送方装置在从进行窗口大小的容量的数据传送之后,至来自接收方的ACK或者窗口更新通知到达为止之间,停止发送处理。因此,不能进行高效率的数据传送。所以,为了进行高效率的数据传送,需要使RWIN_MAX变大。
还有,TCP具有在非专利文献1里所记载的功能,即高速重新发送功能。
图2是与高速重新发送功能有关的收发包的序列图。
如图2所示,在从发送方装置被发送的数据包之中,设数据包P284为发生包损失,而没有到达接收方装置。此时,由于接收了发生包损失的数据包P284以后的数据包P285、P286、P287,所以接收方装置能够判 断出,数据包P284发生了损失,或者因为某些原因而更换了到达顺序。因此,接收方装置在接收了数据包P285的时候,为了将数据包P284未到达的信息通知给发送方装置,会立刻将ACK包P273进行发送。此ACK包就叫做立即确认应答。而且,因为此ACK包P273与以前发送的ACK包P272都是同样的ACK包,所以也叫做重复ACK。以下作为重复ACK来进行说明。以后,直至接收了数据包P284为止,接收方装置会发送与ACK包P272同样的重复ACK包P274、P275。
接下来,接收了此重复ACK包P273、P274、P275的发送方装置,根据连续三次接收了同样的ACK包的结果,检测出重复ACK包所表示的包发生了损失,并立刻重新发送数据包P288。此立刻进行重新发送处理的情况叫做高速重新发送(Fast Retransmission)。
此高速重新发送与后述的由于超时而重新发送的情况相比非常快,使包损失发生时能够迅速地恢复。
但是,在具备网络功能的家用电器、即被称为“网络家电”的装置中,由于其接收性能低,所以在增大RWIN_MAX的情况下,超越了接收性能的包会到达,恐怕反而会降低数据传送效率。
图3是网络家电构成的一个例子的示意图。
网络家电(图中的接收方装置)1是具有与网络7进行有线连接或者无线连接通信功能的装置,例如,具备Ethernet(注册商标)接口。网络7是包含有线或者无线的网络,类似的可以列举出互联网等公共网络等。
接收方装置具备系统总线2、处理部3、存储部4、及通信部5。
通信部5是连接在系统总线2上的硬件。通信部5具有将被储存在存储部4的包发送到网络7的功能与从网络7接收包的功能。而且,通信部5具有将从网络7接收的包进行暂时保持用的存储区域(以下称做FIFO)6。
处理部3是连接在系统总线2上的硬件。既将储存在存储部4的数据作为包来进行构筑处理,又对接收了的包进行分析处理。另外,处理部3还有将发送包从存储部4传送到通信部5的情况,及将储存在通信部5的 FIFO6中的包传送到存储部4的功能的情况。
存储部4具有收发包或保持此数据的功能。
而且,接收方装置1在接收包的情况下,进行如下处理:(1)将从发送方装置8发送的包通过通信部5来接收,并储存在FIFO6中;(2)将储存在FIFO6中的包通过系统总线2传送到存储部4;(3)被传送到存储部4的包的内容通过处理部3来分析;(4)将对接收的包进行分析而得到的分析结果的数据交付到应用程序。
图4是在网络家电的数据传送效率降低的情况下,表示数据传送的一个例子的示意图。另外,图4表示在图3的接收方装置1和发送方装置8之间的数据传送通过TCP来实行的情况下的序列。而且,接收方装置1为网络家电,其接收性能低下,发送方装置8为如PC(Personal Computer)等那样具有较高的发送性能。
这里,用以下例子进行说明。RWIN_MAX:32(设单位为KB、无网络的集中);FIFO6的容量:4(设单位为KB);系统总线2的传送能力:20Mbps;网络7的传送能力:100Mbps。
接收方装置1将窗口大小设定为RWIN_MAX(32KB)的ACK包P31发送到发送方装置8。发送方装置8在接收ACK包P31的情况下,将RWIN_MAX(32KB)容量的数据包P41发送到网络7中。其结果为,在100Mbps的传送能力下,RWIN_MAX(32KB)容量的数据包一下子就到达接收方装置1的通信部5。但是,由于接收方装置1的FIFO6只有4KB,所以不可能将RWIN_MAX(32KB)容量的数据全部储存。
因此,数据包到达后需要立即将此数据包及早地从FIFO6传送到存储部4中。此时,同数据包P41的到达间隔相比,在从FIFO6将已接收完毕的包传送到存储部4的能力更胜一筹的情况下,能够在FIFO6满载之前将已接收完毕的包全部传送到存储部4,因而能够将从发送方装置发送的数据包P41全部接收。而且,相当于PC里的系统总线2的总线最大传送能力,例如在PCI总线的情况下为1064Mbps(133MB/s),与网络7的传送能力相比足够快。
但是,在接收方装置1是网络家电等的情况下,从FIFO6传送到存储部4的传送能力次于网络7的传送能力的情况较多。在本例中,以从FIFO6传送到存储部4的传送能力和到达通信部5的包的速度、即网络7的传送能力相差5倍的情况来进行说明。
接收方装置1在接收第一个数据包P41-1的情况下,从FIFO6将已接收完毕的包传送到存储部4。如果设此数据传送所需的时间为5T,因为传送性能的差为5倍,所以从网络7到达的数据包的间隔为T。因此,在这个5T的间隔内,就会有5个数据包到达接收方装置1。但是,FIFO6的容量为4KB。因此,在第5个数据包到达的时候可用空间即会不足,此数据包会从FIFO6溢出。这样,其后的数据也会发生包损失,致使在此之后进行不必要的重新发送。结果,由于将RWIN_MAX过份加大,且由于多次发生不必要的重新发送而使传送效率降低。为此,一般在像网络家电等那样的低性能通信装置中,配合FIFO6的容量来设定RWIN_MAX的最大限度。
如此在将RWIN_MAX设定为与FIFO6的容量(4KB)相一致的值的情况下,在RTT是10毫秒的环境中,和内部总线1的传送能力是20Mbps的性能相比,4KB/10毫秒=3.2Mbps的包传送性能是比较低的。而且,假设FIFO6的容量为RWIN_MAX(32KB)的情况下,可以将RWIN_MAX作为32KB来通知,即为32KB/10毫秒=25.6Mbps,即使受内部总线的性能的限制,也能够获取20Mbps的传送性能。
并且,在网络家电中,由于其处理能力较低,根据RWIN_MAX的设定值,接收能力有可能会大幅度下降。
图5是处理能力较高的接收方装置(例如PC等)的接收处理的序列图。另外,以RWIN_MAX为4的情况为例进行说明。
首先,如图5所示,在由发送方装置所发送的数据包P301、P302、P303之中,设数据包P302为因为包损失而没有到达接收方装置。此时,接收方装置通过接收数据包P301,而发送ACK包P291。接收了ACK包P291的发送方装置,根据已经达到序列号码11及窗口大小为4的情况, 将后续的数据包P304进行发送。另一方面,接收方装置在序列号码12的数据包P302到达之前,通过接收序列号码13的数据包P303,检测数据包P302是发生了包损失还是更换了顺序,并且在接收数据包P303之后,立刻发送立即确认应答P292。还有,接收方装置通过接收数据包P304,而发送立即确认应答P294、P295。
其次,发送方装置通过接收三个立即确认应答,使高速重新发送功能进行工作,将序列号码12的数据包P305重新发送。这样,在发生包损失的情况下,能够通过高速的重新发送功能来恢复通信。
图6是处理能力较低的接收方装置(例如网络家电等)的接收处理的序列图。另外,以RWIN_MAX为4的情况为例进行说明。
首先,如图6所示,在由发送方装置所发送的数据包P321、P322、P323之中,设数据包P322为因为包损失而没有到达接收方装置。尤其在接收方装置的接收能力较低的情况下,数据会从接收方装置的FIFO6中溢出,即使网络不集中也会引起包损失。此时,接收方装置通过接收数据包P321,而发送ACK包P311。此时,因为在接收方装置中,所接收的数据包P321的接收处理尚未完成,所以接收方装置所发送的ACK包P311的窗口大小为2。因此,从接收了ACK包P311的发送方装置没有发送任何数据包。此后,接收方装置在序列号码12的数据包P322到达之前,通过接收序列号码13的数据包P323,检测数据包P322是发生了包损失还是更换了顺序,并且在接收数据包P323之后,立刻发送立即确认应答P312。此时的窗口大小也因为接收处理尚未完成,所以窗口大小为2。此后,接收处理结束了的接收方装置将窗口大小为4的窗口更新通知包P313进行发送。接收了窗口更新通知包P313的发送方装置,根据序列号码为11、窗口大小为4的情况,将序列号码14、15的数据包P324进行发送。而且,接收了数据包P324的接收方装置将立即确认应答P314、P315进行发送。此时,接收方装置连续发送两个立即确认应答包。因此,在发送方装置中高速重新发送功能不工作。因此,由于发送方装置没有接收序列号码12的ACK包,所以经过超时时间T1之后,进行因超时而进行的重新发送 (P325)。这样,在处理能力较低的情况下,由于接收方装置不能够连续进行立即确认应答,所以高速重新发送功能不工作,且成为等待超时的低速重新发送。因此,即使是很少的包损失也会根本得不出传送速率。
因此,在现有的FIFO6的容量下,在通知大的RWIN_MAX的同时,也不使包损失发生,且即使在较大的RTT的环境里,为了最大限度地发挥网络家电的接收能力,需要通过接收方装置来控制发送方装置所发送的数据的发送速率。还有,即使发生包损失,也不要招致速率过于降低。
专利文献1中公开了,通过接收方装置来控制发送方装置的数据发送速率的方法。如果根据专利文献1的方式,在生成对应于接收了的数据的ACK的情况下,不立刻进行发送而暂时将ACK包保持在ACK发送队列里。然后,按照下面的(1)及(2),通过以有规律的间隔进行ACK的发送来控制数据发送速率。
(1)在ACK发送队列内的剩余ACK包不足规定数的情况下,将应该被发送的ACK进行分割;(2)每发送一个ACK,就使窗口大小增加1MSS。
图7是在专利文献1中的、表示数据包和ACK包之间互相传递的序列图。
接收方装置在接收从发送方装置发送的数据包P61的情况下,生成对发送方装置发送的ACK包,并插入ACK发送队列中。另外,此时生成的ACK包是ACK号码10的ACK包。此后,接收方装置在通过有规律的间隔而决定的规定时刻,发送ACK包P51。在进行ACK包的发送时,因为ACK发送队列中的ACK包不足规定数(作为2来说明),所以ACK包P51进行ACK分割。因此,ACK号码不是10,而是9.1。而且,窗口大小增加了1MSS而成为2。
其次,接收了ACK包P51的发送方装置根据接收窗口大小2的包,能够将序列号码9.1至11.1进行发送,从而发送尚未发送的后续的数据(即序列号码10的数据包P62)。
还有,接收方装置发送ACK包P51以后,在按照有规律的间隔被决定的规定时刻到来时,将ACK包P52进行发送。在进行ACK包发送时,因为ACK发送队列中的ACK包不足规定数(作为2来说明),所以ACK包P52也进行ACK分割。因此,ACK号码不是10,而是9.2,窗口大小增加了1MSS而成为3。接收了此ACK包P52的发送方装置,与ACK包P51的接收时一样,能够将序列号码9.2至12.2进行发送,从而发送尚未发送的后续的数据(即序列号码11的数据包P63)。
以后,同样地一边按照每1MSS增加窗口大小,一边按照有规律的间隔将ACK包P53、P54进行发送。
这样,以有规律的间隔进行ACK分割,并按照每1MSS来增加窗口大小,且通过发送ACK包来控制发送方装置发送的数据包的间隔。
专利文献1:日本特许第3617649号公报
非专利文献1:标准规格书<RFC2001>、IETF、(2006年7月21日检索),互联网<URL:http://www.ietf.org/rfc/rfc2001.txt>
但是,专利文献1的方法中,在发送前将对应于已经接收的数据的ACK暂时保持在队列里,并通过以有规律的间隔进行ACK分割且使窗口大小按照每1MSS增加的方法,对从发送方装置发送的发送速率进行控制,因此能够对从接收方装置发送的发送速率进行控制,但是该方法存在以下问题:
(1)如果不进行数据接收就不能开始控制的问题;(2)由于进行ACK分割而带来处理负荷的问题;(3)由于以1MSS来增加窗口大小而需要控制细小的ACK发送间隔,因此增加处理负荷的问题;(4)在发生包损失时没有对应的问题。
例如,设RTT为10毫秒,如图7所示,在1RTT(10毫秒)之间就会进行4次ACK发送。因此,ACK发送间隔为2.5毫秒。但是,在2.5毫秒间隔的ACK发送中,RTT内的能够增加的RWIN_MAX到5为止。假如在要使RWIN_MAX增加到32的情况下,就需要设ACK发送间隔为:10毫秒/(32-1)=0.32毫秒,因此增加处理负荷。例如,在CPU工作时钟为133MHz的网络家电设备中,接收1MSS的数据包的处理所需时间大约为0.3毫秒,而且,发送ACK包的处理所需时间大约为0.2毫秒。因此,在此种例子的情况下,以0.32毫秒的间隔进行ACK发送处理是不可能的。
发明内容
在此,本发明鉴于上述的问题,第一个目的在于,对于发送数据的发送方装置,在对应本身的接收能力而自发地控制数据的发送通信量的同时,提供减轻其控制处理负担的通信装置。并且,第二个目的在于提供,在发生包损失的时候,也能够催促发送装置将消失的包迅速地重新发送的通信装置。
为了达到上述目的,涉及本发明的通信装置,接收从其他的通信装置发送的数据,其特征在于,包括:接收单元,接收所述数据;第一包生成单元,生成针对在所述接收单元所接收的数据的、表示对所述其他的通信装置的应答内容的确认应答包,并且将其发送到所述其他的通信装置;以及第二包生成单元,无论在所述接收单元的数据的接收结果如何,都生成对所述其他的通信装置请求数据发送的数据请求包,并且将其发送到所述其他的通信装置;所述第二包生成单元为了使能够接收的数据的大小作为接收大小而被包含在所述数据请求包中,而生成该数据请求包;所述通信装置还包括:大小计算单元,通过在所述接收大小上加上更新量,来更新该接收大小,所述第二包生成单元每经过一段更新时间,就使所述大小计算单元更新所述接收大小,并生成包含被更新的接收大小的所述数据请求包,且发送到所述其他的通信装置;所述通信装置还包括:更新决定单元,根据所述通信装置的通信能力,来决定所述更新时间及所述更新量。
因此,由于无论从其他的通信装置发送的数据的接收结果如何,对其他的通信装置请求数据的发送的窗口更新通知包、即数据请求包都被发送到其他的通信装置,所以能够在任意定时自发地控制从其他的通信装置发送的数据量。例如,能够不等接收来自其他的通信装置的数据而进行控制。并且,因为不需要进行分割ACK之类的处理,也不需要将多个ACK以短 的发送间隔进行发送,所以能够减轻控制处理负担。还有,因为数据请求包里包含接收大小,所以对于其他的通信装置能够通知可接收数据的大小,其结果为,能够实现对应接收能力的发送通信量的控制。
因此,每经过一段更新时间,也就是规定的更新间隔,窗口大小即接收大小按每个更新量来增加,因为窗口更新通知包即数据请求包被发送,所以能够控制其他的通信装置的发送数据的通信量模式,还能够进行配合通信装置的处理的数据的接收。而且,依据窗口大小按每个更新量来增加的情况,能够将从其他的通信装置连续发送的数据量作为更新量。其结果为,在接收那些数据的通信装置中,能够将在所接收的数据提交给应用程序之前暂时进行储存的存储器的容量消减到更新量。
因此,能够将依据其他的通信装置的数据发送模式,与对应通信装置的通信能力的通信量模式相配合。
而且,还可以包括以下特征:所述接收单元作为具有用于暂时保持被接收的数据的存储器的物理层通信设备而被构成,所述更新决定单元根据所述存储器的容量和被保持在所述存储器中的数据的传送能力,来决定所述更新时间及所述更新量。
因此,能够将通过其他的通信装置的数据的发送模式与适合物理层通信设备的能力的通信量模式相配合,可以防止在物理层通信设备中的包损失。
而且,所述通信装置的特征在于,还可以包括:处理单元,处理由所述接收单元所接收的数据,所述更新决定单元还根据所述处理单元的处理能力,来决定所述更新时间。
因此,能够将通过其他的通信装置的数据的发送模式与适合通信装置的数据处理能力的通信量模式相配合,可以控制为了通信装置的通信及数据处理而分割出来的处理量。
而且,还可以包括以下特征:所述更新决定单元根据在所述通信装置中工作的应用程序所需要的比特率决定所述更新时间。
因此,能够将依据其他的通信装置的数据的发送模式,与适合于通信装置中的应用程序所需要的比特率的通信量模式相配合,可以防止超出应用程序需要的不必要的通信量的发生。
而且,还可以包括以下特征:所述第二包生成单元在每经过一段所述更新时间而生成所述数据请求包之时,在通过所述接收单元接收数据的情况下,停止生成所述数据请求包。
因此,由于窗口更新通知包即数据请求包的发送被停止,也就是窗口更新通知功能被停止,能够防止数据请求包被连续发送且其他的通信装置发送数据的发送速率无限制地上升的情况。
而且,还可以包括以下特征:所述第二包生成单元在每经过一段更新时间所进行的所述数据请求包的生成停止之时,在通过所述接收单元接收数据的情况下,重新开始每经过一段所述更新时间而进行的所述数据请求包的生成。
因此,能够在其他的通信装置停止数据发送又重新开始时,再次,控制配合通信装置的通信能力的通信量模式。
而且,所述大小计算单元还包括以下特征:在所述通信装置中工作的应用程序取得所需要的数据总量,并算出由所述接收单元所接收的数据的接收量随着接近所述总量而减少的应答大小。第一包生成单元生成,作为所述应答内容的、将能够接收的数据的大小作为所述应答大小来表示的所述确认应答包。
因此,由于配合一系列的数据接收结束的定时,对应那些数据的ACK包、即确认应答包的应答大小(窗口大小)减小,其他的通信装置在重新开始数据发送之时,能够按照此减小的应答大小来限制在重新开始时从其他的装置发送的数据的量,所以能够配合通信装置的接收能力重新开始数据发送。
而且,还可以包括以下特征:所述第一包生成单元生成表示将能够接收的数据的大小作为应答大小的所述确认应答包,在每经过一段所述更新时间而进行的所述数据请求包的生成停止之时,在先发送的损失了的数据 被重新发送并且由所述接收单元接收的情况下,所述第一包生成单元生成表示比上次生成的所述确认应答包的应答大小小的应答大小的确认应答包,所述第二包生成单元重新开始每经过一段所述更新时间而进行的所述数据请求包的生成。
因此,即使是在包损失发生时,也能够进行发送数据的速率控制。
而且,所述通信装置的特征在于,还可以包括:延迟单元,在每经过一段所述更新时间而进行的所述数据请求包的生成停止之时,延迟通过所述第一包生成单元所进行的所述确认应答包的发送的定时。
因此,由于确认应答包的发送定时晚,即使从其他的发送装置被连续发送的各个数据的接收时刻的间隔产生波动,也能够继续维持所控制的通信量模式。例如,从其他的通信装置发送的多个数据的接收,和对应那些数据的来自通信装置的多个确认应答包(ACK包)的发送,各自每经过一段更新时间,也就是以规定间隔来进行。如此之时,在从其他的通信装置发送的数据以比规定间隔短的间隔被接收时,接收了此数据的通信装置,不立即发送对应此数据的确认应答包,而延迟确认应答包的发送。即,通信装置在从上次发送确认应答包起到经过更新时间之后,发送此确认应答包。
而且,还可以包括以下特征:所述接收单元作为具有用于暂时保持被接收的数据的存储器的物理层通信设备而被构成,所述通信装置还具备发送间隔决定单元,根据所述存储器的容量和被保持在所述存储器中的数据的传送能力,来决定所述确认应答包的发送间隔,所述延迟单元为了按照由所述发送间隔决定单元决定的发送间隔来发送多个所述确认应答包,而延迟所述定时。
因此,因为根据存储器的容量和传送能力的发送间隔来发送确认应答包,所以能够将通过其他的通信装置的数据的发送模式,与适合物理层通信设备的能力的通信量模式相配合,可以防止在物理层通信设备中的包损失。
而且,所述通信装置的特征在于,还可以包括:处理单元,处理由所述接收单元所接收的数据,以及发送间隔决定单元,根据所述处理单元的 处理能力来决定所述确认应答包的发送间隔,所述延迟单元为了按照由所述发送间隔决定单元决定的发送间隔来发送多个所述确认应答包,而延迟所述定时。
因此,能够将通过其他的通信装置的数据的发送模式与适合通信装置的数据处理能力的通信量模式相配合,可以控制为了通信装置的通信及数据处理而分出的处理量。
而且,所述通信装置的特征在于,还可以包括:发送间隔决定单元,根据在所述通信装置中工作的应用程序所需要的比特率,来决定所述确认应答包的发送间隔,所述延迟单元为了按照由所述发送间隔决定单元决定的发送间隔来发送多个所述确认应答包,而延迟所述定时。
因此,能够将依据其他的通信装置的数据的发送模式,与适合于通信装置中的应用程序所需要的比特率的通信量模式相配合,可以防止超出应用程序需要的不必要的通信量的发生。
而且,所述通信装置的特征在于,还可以包括:发送间隔决定单元,根据接收速率改变的请求,来决定所述确认应答包的发送间隔,所述延迟单元为了按照由所述发送间隔决定单元决定的发送间隔来发送多个所述确认应答包,而延迟所述定时。
因此,在产生接收速率改变的请求之时,由于按照根据该请求的发送间隔来发送确认应答包,所以能够将依据其他的通信装置的数据的发送模式,与适合该请求的通信量相配合。
而且,还可以包括以下特征:所述第一包生成单元生成表示将能够接收的数据的大小作为应答大小的所述确认应答包,所述延迟单元进一步将通过所述第一包生成单元生成的所述确认应答包所表示的应答大小,根据接收速率改变的请求进行改变。
因此,在产生接收速率改变的请求之时,由于表示根据该请求的应答大小(窗口大小)的确认应答包(ACK包)被发送,所以能够将依据其他的通信装置的数据的发送模式,与适合该请求的通信量相配合。
而且,还可以包括以下特征:所述第二包生成单元在由所述接收单元 所接收的数据的接收量超出阈值之时,开始每经过一段所述更新时间而进行的所述数据请求包的生成。
因此,即便使其他的通信装置的数据发送速率逐渐增加,也能够将依据其他的通信的数据的发送模式,与对应通信装置的通信能力的通信量模式相配合。
而且,还可以包括以下特征:所述第二包生成单元生成包含被请求数据的开头号码的所述数据请求包,在由所述接收单元所接收的数据的接收量超出阈值之时,以按顺序发送的所述数据请求包的开头号码增加的状态,开始每经过一段所述更新时间而进行的所述数据请求包的生成。
因此,在数据的接收量超出阈值之时,窗口更新通知包即数据请求包每经过一段更新时间就被发送。而且,各个数据请求包的窗口大小即接收大小和ACK号码即开头号码比上次的数据请求包的接收大小和开头号码有所增加。其结果为,能够将依据其他的通信装置的数据的发送模式,与对应通信装置的通信能力的通信量模式准确地配合。
而且,所述通信装置的特征在于,还可以包括:检测单元,对从所述其他的通信装置发送的数据的损失进行检测,所述第一包生成单元生成表示将能够接收的数据的大小作为应答大小的所述确认应答包,在通过所述检测单元检测出损失之时,生成表示比上次生成的确认应答包的应答大小小的应答大小的确认应答包。例如,所述第一包生成单元生成,表示将上次生成的确认应答包的应答大小和损失的数据的量之间的差作为所述小的应答大小的所述确认应答包。
因此,在发生包损失之时,由于确认应答包(ACK包)的应答大小(窗口大小)变小,所以通过其他的通信装置的数据的发送速率降低,能够抑制包损失的发生。
而且,可以包括以下特征:所述第一包生成单元还在通过所述检测单元在规定时间内未检测出损失之时,生成表示比上次生成的确认应答包的应答大小大的应答大小的确认应答包。
因此,在规定的时间内没有发生包损失之时,由于确认应答包(ACK 包)的应答大小(窗口大小)变大,所以通过其他的通信装置的数据的发送速率提高,能够提高数据发送效率。
而且,可以包括以下特征:所述第二包生成单元生成所述数据请求包,所述数据请求包是在由所述其他的通信装置按顺序发送的数据没有按照预先规定的顺序被所述接收单元所接收的情况下,或者,作为在所述数据发生损失的情况下应当被发送的否定应答包而被生成的。例如,所述第二包生成单元在发生数据的损失的情况下,生成规定数的所述数据请求包并将其发送,所述数据请求包在数据的损失发生的情况下,表示与针对紧接损失发生之前通过所述接收单元所接收的数据的确认应答包相同的内容。
因此,即使损失了从其他的通信装置发送的数据,无论从其他的通信装置发送的数据的接收结果如何,都能够对其他的通信装置诱发高速重新发送功能。其结果为,不等超时,就能够接收损失的数据。
而且,所述通信装置的特征在于,可以包括:损失检测单元,对在所述接收单元所接收的数据之中消失的损失数据进行检测,所述第一包生成单元,作为对从所述其他的通信装置发送的数据的确认应答,将所述确认应答包发送到所述其他的通信装置,所述确认应答包指示将通过所述损失检测单元所检测的损失数据重新发送,所述第二包生成单元,在通过所述第一包生成单元发送的确认应答包的发送数,不足使其对所述其他的通信装置执行所述损失数据的重新发送的必要数的情况下,无论所述其他的通信装置的数据的发送如何,从所述必要数中减去发送数的复制数,将所述确认应答包作为所述数据请求包并按所述复制数发送到所述其他的通信装置。
例如,在其他的通用通信装置接收各自作为确认应答包的三个DupAck的时候,重新发送表示此DupAck的损失数据。即,对其他的通信装置执行损失数据的重新发送的DupAck的必要数是“3”。在此情况下,涉及本发明的通信装置的第一包生成单元,作为对来自其他的通信装置的包的发送的接收应答,发送DupAck(确认应答包),第二包生成单元,在此DupAck的发送数不足必要数“3”的情况下,无论从其他的通信装置的数 据包的发送如何,从该必要数“3”中减去发送数的复制数,将DupAck作为数据请求包并按所述复制数发送到其他的通信装置。因此,例如,在第一包生成单元发送两个DupAck的时候(发送数是“2”),第二包生成单元,尽管从其他的通信装置没有接受包,也发送一个DupAck。
因此,即使在通信装置的资源不充分的情况下,即,在由于通信装置中的接收处理的延迟,TCP窗口大小不恢复的情况下,也能够不等到超时,就能使其他的通信装置启动损失数据的高速重新发送。其结果为,由于损失数据而带来的吞吐量降低能够被抑制在最小限度。而且,可以不用像以往例那样,对其他的通信装置请求解释ELN的功能,能够促使通用的通信装置进行高速重新发送。
而且,因为从由接收单元所取得的数据中检测出损失数据,所以不会发送指示重新发送由于网络处于负荷过大状态而消失的数据(例如TCP包)之类的错误的DupAck。因此,能够防止对应如此的DupAck,其他的通信装置在负荷过大状态的网络中又发送数据,使之发生不必要的通信量。
而且,可以包括以下特征:所述接收单元具备存储器,将从所述其他的通信装置发送的数据按顺序取得并储存在所述存储器中,所述损失检测单元对未储存在所述存储器中就消失的损失数据进行检测。
因此,例如由于从接收用FIFO存储器溢出而消失了的损失数据确实地被检测,所以能够确实地促使其他的通信装置进行高速重新发送。
而且,所述通信装置的特征在于,还可以包括:网络处理单元,从所述接收单元取得数据,对所述数据进行作为OSI参照模式的网络层的处理,所述损失检测单元检测在所述网络处理单元中消失的损失数据。
因此,例如进行IP(Internet Protocol)处理的网络处理单元,即由于在IP处理部中消失了的损失数据确实地被检测,所以能够确实地促使其他的通信装置进行高速重新发送。
而且,可以包括以下特征:所述损失检测单元只有在消失的损失数据是根据TCP(Transmission Control Protocol)的数据的情况下,检测所述 损失数据。
因此,能够防止对于TCP包以外的损失数据发送错误的确认应答包或者数据请求包,对应如此的包而从其他的通信装置中发送数据,可以防止发生不必要的通信量。
而且,所述通信装置的特征在于,还可以包括:装置确定单元,根据在所述接收单元取得的数据来确定重新发送指示的对象的所述其他的通信装置。
例如,根据通过从接收单元取得的数据所示的IP地址或端口号码等,而确定重新发送指示的对象,能够确实地对成为数据的发送方的其他的通信装置发送确认应答包或者数据请求包,并且能够抑制由于对错误的装置发送重新发送指示信号而发生的不必要的通信量。
而且,可以包括以下特征:所述损失检测单元在检测损失数据之时先保持所述检测结果,所述通信装置还包括复位单元,在由所述损失检测单元进行的损失数据的检测经过规定时间的时候、所述通信装置发送规定数的数据的时候、依据所述通信装置的数据处理速度比所述损失数据的检测之时慢的时候、或者在由所述第二包生成单元发送数据请求包的时候,删除由所述损失检测单元保持的检测结果。
因此,由于通过损失检测保持的检测结果(包损失信息)被删除,所以尽管从其他的通信装置重新发送数据,也能够防止错误发送确认应答包或者数据请求包,从而能够抑制因如此的错误包而发生的不必要的通信量。而且,在从损失数据的检测起到经过规定时间之时检测结果被删除的情况下,能够按照规定时间的经过确实地删除检测结果。并且,在通信装置发送规定数的数据之时检测结果被删除的情况下,不需要计时器功能等就能够在适当的定时简单地删除检测结果。而且,在依据通信装置的数据的处理速度(例如,PPS(Packet Per Sec:包/秒))比检测损失数据时变慢之时检测结果被删除的情况下,尽管通信装置处于负荷过大状态,由于检测结果被保持,所以能够防止发送确认应答包或者数据请求包,并能够对应此包而从其他的通信装置中发送数据,可以抑制发生不必要的通信量。还有, 能够防止损失数据的检测和此检测结果的删除被频繁地重复进行,并能够在适当的定时删除检测结果。并且,依据所述第二包生成单元发送数据请求包时检测结果被删除的情况下,能够发送合适的确认应答包或者数据请求包。例如,如果在数据请求包被发送以后未删除检测结果,损失数据再次被检测之时,第一及第二包生成单元有可能发送指示重新发送错误的损失数据的确认应答包或者数据请求包。因此,本发明通过在如上述的定时删除检测结果,而能够发送合适的重新发送指示信号。
而且,可以包括以下特征:所述第二包生成单元在由所述第一包生成单元生成确认应答包之时,计算所述复制数。
因此,由于复制数被提早算出,所以第二包生成单元能够紧急发送此被算出的复制数的数据请求包,其结果为,能够对其他的通信装置最快速地启动高速重新发送。并且,因为第二包生成单元能够紧急发送数据请求包,所以没有必要长时间保持此数据请求包或与此包有关系的信息等。其结果为,能够消减存储器容量。
而且,可以包括以下特征:所述第二包生成单元在从所述第一包生成单元发送确认应答包以后到经过规定期间之前,从所述确认应答包被发送以后到经过规定期间之前且所述通信装置的负荷率变为规定阈值以下时,或者,在所述通信装置将所述通信装置能够接收的数据量增加的情况通知给所述其他的通信装置之前,计算所述复制数。
因此,在由第一包生成单元发送确认应答包以后到经过规定期间(例如,超时期间)之前,复制数被算出的情况下,第二包生成单元能够在此规定期间确实地计算从第一包生成单元发送的确认应答包的发送数,并能够算出正确的复制数。而且,在从确认应答包被发送以后到经过规定期间之前、且所述通信装置的负荷率(例如,CPU的使用率)变为规定的阈值以下时复制数被算出的情况下,能够与上述同样地算出正确的复制数的同时,第二包生成单元在通信装置的负荷小的时候,能够适当地生成数据请求包。并且,在通信装置将通信装置的能够接收的数据量增加了的情况(例如,WinUpdate)通知给其他的通信装置之前,复制数被算出的情况下,能够与 上述同样地算出正确的复制数。
还有,例如,在WinUpdate被通知给其他的通信装置之后,复制数被算出,此后,在此复制数的DupAck作为数据请求包从第二包生成单元被发送的情况下,其他的通信装置辨别从第一包生成单元发送的DupAck(确认应答包)和从第二包生成单元发送的DupAck(数据请求包)。因此,其他的通信装置判断出对于损失数据没有发送必要数的同样的DupAck,有对此损失数据不执行高速重新发送的情况。在此,本发明通过像上述一样地在通知WinUpdate之前算出复制数,能够在通知WinUpdate之前发送此复制数的DupAck,并能够确实地促使其他的通信装置进行高速重新发送。
而且,可以包括以下特征:所述第二包生成单元根据在所述通信装置能够接收的数据量计算所述复制数。例如,所述第二包生成单元在由所述第一包生成单元发送最初的确认应答包之时,根据所述能够接收的数据量,计算所述第一包生成单元预定发送的发送数,通过从所述必要数中减去所述发送数,来计算所述复制数。
因此,在最初的确认应答包被发送之时,由于从第一包生成单元发送的预定的发送数,例如根据Window大小被算出,再根据此发送数算出复制数,所以能够在此最初的确认应答包被发送之后,第二包生成单元紧急发送此复制数的数据请求包。
而且,可以包括以下特征:所述第二包生成单元在所述复制数为两个以上的时候,复制OSI参照模式的数据链路层或者传输层所具有的数据请求包,并发送所述复制数的数据请求包信号。
因此,在数据链路层中所具有的、作为MAC(Media Access Control:媒体接入控制)帧被构筑的DupAck(确认应答包)被复制的情况下,由于此原来复制的DupAck被完成为可以发送的状态,所以在能够消减重新发送DupAck所需要的存储容量的同时,还能够降低CPU的处理负荷。而且,在传输层中所具有的、作为TCP包被构筑的DupAck(确认应答包)被复制的情况下,能够在传输层(TCP)容易地进行此复制数的管理。其结果为,例如对既存的通信装置适用本发明的时候,能够对此传输层进行修复,也能 够限定修复部分。
而且,本发明不仅能够作为这样的通信装置来实现,也能够作为其方法或程序、储存此程序的存储介质、集成电路来实现。
本发明的通信装置能够控制发送方的其他的通信装置的发送数据速率,抑制由于接收超过处理能力的数据而发生的包损失,防止吞吐量降低。并且,由于控制发送方的其他的通信装置的发送速率,能够进行高效率的数据传送并得到最大的吞吐量。
附图说明
图1是在TCP中收发数据的序列图。
图2是与高速重新发送功能有关的收发包的序列图。
图3是网络家电的框图。
图4是在数据传送效率降低的情况下,表示数据传送的一个例子的示意图。
图5是在高速接收方装置中收发包的序列图。
图6是在低速接收方装置中收发包的序列图。
图7是在现有技术中的收发TCP的序列图。
图8是涉及本发明的实施例1的网络和通信装置的结构的一个例子的框图。
图9是涉及本发明的实施例1的处理部的功能结构例的框图。
图10是在本发明的实施例1中收发包的序列图。
图11是涉及本发明的实施例2的处理部的功能结构例的框图。
图12是在本发明的实施例2中收发包的序列图。
图13是在本发明的实施例2的接收方装置的工作流程图。
图14是涉及本发明的实施例3的处理部的功能结构例的框图。
图15是在本发明的实施例3中收发包的序列图。
图16是在本发明的实施例4中收发包的序列图。
图17是涉及本发明的实施例5的处理部的功能结构例的框图。
图18是在本发明的实施例5中收发包的序列图。
图19是在本发明的实施例5中收发其他的包的序列图。
图20是在本发明的实施例6中收发包的序列图。
图21是在本发明的实施例6中收发其他的包的序列图。
图22是涉及本发明的实施例7的处理部的功能结构例的框图。
图23是在本发明的实施例7中收发包的序列图。
图24是在本发明的实施例7中收发其他的包的序列图。
图25是涉及本发明的实施例8的处理部的功能结构例的框图。
图26是在本发明的实施例8的收发包的序列图。
图27是在本发明的实施例8的收发其他的包的序列图。
图28是涉及本发明的实施例9的处理部的功能结构例的框图。
图29是在本发明的实施例9的收发包的序列图。
图30是表示在本发明的实施例10的网络的结构例和通信装置的结构例的框图。
图31是在本发明的实施例10的通信装置的CPU功能结构的框图。
图32是在本发明的实施例10的通信装置之间的通信序列的示意图。
图33是在本发明的实施例10的接收方装置中的处理序列的例子的示意图。
图34是在本发明的实施例10的DupAck管理部的DupAck复制数计算处理的流程图。
图35是涉及实施例10的变形例1的网络结构例及通信装置的结构例的示意图。
图36是涉及实施例10变形例1的接收方装置的CPU功能结构的框图。
图37是涉及实施例10的变形例1的接收方装置的处理序列的例子的示意图。
图38是涉及实施例10的变形例2的接收方装置的CPU功能结构的框图。
图39是涉及在实施例10的变形例3的通信装置之间的通信序列的示意图。
图40是涉及实施例10的变形例3的接收方装置的处理序列的例子的示意图。
图41是涉及实施例10的变形例3的DupAck管理部的DupAck复制数计算处理的流程图。
附图标记说明
1  接收方装置
2  系统总线
3  处理部
4  存储部
5  通信部
6  FIFO
7  网络
8  发送方装置
31  接收方装置
32  系统总线
33  处理部
34  存储部
35  通信部
36  FIFO
37  网络
38  发送方装置
41  IP处理部
42  TCP处理部
43  应用程序处理部
44  TCP包处理部
45  ACK生成部
46  窗口更新通知生成部
47  接收缓存
48  窗口大小计算部
49  窗口更新计时器部
50  接收速率决定部
51  上次RWIN存储部
61  IP处理部
62  TCP处理部
63  应用程序处理部
64  TCP包处理部
65  ACK生成部
66  窗口更新通知生成部
67  接收缓存
68  窗口大小计算部
69  窗口更新计时器部
70  接收速率决定部
71  上次RWIN存储部
81  IP处理部
82  TCP处理部
83  应用程序处理部
84  TCP包处理部
85  ACK生成部
86  窗口更新通知生成部
87  接收缓存
88  窗口大小计算部
89  窗口更新计时器部
90  接收速率决定部
91  上次RWIN存储部
101  IP处理部
102  TCP处理部
103  应用程序处理部
104  TCP包处理部
105  ACK生成部
106  窗口更新通知生成部
107  接收缓存
108  窗口大小计算部
109  窗口更新计时器部
110  接收速率决定部
111  上次RWIN存储部
112  ACK延迟部
121  IP处理部
122  TCP处理部
123  应用程序处理部
124  TCP包处理部
125  ACK生成部
126  窗口更新通知生成部
127  接收缓存
128  窗口大小计算部
129  窗口更新计时器部
130  接收速率决定部
131  上次RWIN存储部
141  IP处理部
142  TCP处理部
143  应用程序处理部
144  TCP包处理部
145  ACK生成部
146  窗口更新通知生成部
147  接收缓存
148  窗口大小计算部
149  上次RWIN存储部
150  包损失检测部
161  IP处理部
162  TCP处理部
163  应用程序处理部
164  TCP包处理部
165  ACK生成部
166  重复ACK生成部
167  接收缓存
168  窗口大小计算部
169  包遗漏检测部
具体实施方式
以下,参照附图来说明本发明的具体实施方式。而且,在实施例的说明中,虽然是将使用TCP的通信作为例子来进行说明的,但是在与TCP同样的、通过确认应答包来通知能够接收的缓存可用空间的同类的通信协议中,也可以适用本发明。还有,在实施例的说明中,设专门用于接收的通信装置为接收方装置、专门用于发送的通信装置为发送方装置,并且认为接收方装置适用于本发明来进行说明,但是,也可以是接收方装置及发送方装置的双方兼具收发功能,并且也可以将本发明适用于发送方装置。
(实施例1)
图8是涉及本实施例的通信装置(接收方装置)的结构的一个例子的示意图。接收方装置31是具有与网络37进行有线连接或者无线连接通信功能的装置,例如,具备Ethernet(注册商标)接口。网络37包含有线 网络或者无线网络,可以列举如互联网等公共网络。
接收方装置31具备系统总线32、处理部33、存储部34、及通信部35。
通信部35是连接在系统总线32上的硬件。通信部35具有将储存在存储部34的包向网络37进行发送的功能,及从网络37接收包的功能。而且,通信部35具有用于将从网络37接收的包进行暂时保持用的存储区域(以下称做FIFO)36。另外,在实施例1至10中通信部是作为接收单元来构成的。
处理部33是连接在系统总线32上的硬件。处理部33既将储存在存储部34的数据作为包来进行构筑处理,又对接收了的包进行分析处理。另外,处理部33还有将发送包从存储部34传送到通信部35的情况,及将储存在通信部35的FIFO36中的包传送到存储部34的功能的情况。
存储部34具有收发包或保持此数据的功能。
这里,对接收方装置31的接收处理进行说明。接收方装置31在从网络37接收包的情况下,首先将接收了的包储存在通信部35的FIFO36中。其次,接收方装置31将储存在FIFO36中的接收包,从FIFO36通过系统总线32传送到存储部34。被传送到存储部34的接收包的内容,通过处理部33进行分析并进行接收处理。处理部33在得到分析结果的情况下,向应用程序提交接收了的数据。
图9是在本实施例的接收方装置31中的处理部33的功能结构的一个例子的框图。而且,在本实施例中,TCP处理部42作为在处理部33被执行的程序而被构成,但也可以是安装在LSI(Large Scale Integration:大规模集成电路)等的情况。另外,图中的实线表示收发包的数据流,虚线表示与控制信息的互相传递有关的流。
处理部33具备IP处理部41、TCP处理部42及应用程序处理部43。
接收方装置31的TCP处理部42具有:TCP包处理部44、接收缓存47、窗口大小计算部48、窗口更新计时器部49、接收速率决定部50、及上次RWIN存储部51。接下来,对这些组成部分进行说明。
TCP包处理部44具有TCP包的收发处理功能。TCP包处理部44对接收了的包的应用程序进行确认,并为了将此包提交给应用程序而将其储存在接收缓存47中。并且,TCP包处理部44具有构筑TCP包、再将其交付到IP处理部41、且作为TCP/IP包进行发送的功能。另外,TCP包处理部44包括ACK生成部45和窗口更新通知生成部46。
ACK生成部45根据接收的TCP包的序列号码,来决定ACK号码以生成ACK包。在ACK包中,从窗口大小计算部48得到的、目前能够接收的可用空间(以下称做窗口大小)也被设定。而且,在实施例1至9中,ACK生成部作为第一包生成单元被构成,ACK包相当于确认应答包。另外,在ACK包中所设定的窗口大小相当于应答大小。
窗口更新通知生成部46在接收缓存47的可用空间发生增加的时候,生成窗口更新通知包。并且,窗口更新通知生成部46具有,根据来自窗口更新计时器部49的指示而生成窗口更新通知包的功能。在窗口更新通知包中,设定有从窗口大小计算部48得到的窗口大小。而且,在实施例1至9中,窗口更新通知生成部作为第二包生成单元被构成,窗口更新通知包相当于数据请求包。另外,在窗口更新通知包中所设定的窗口大小相当于接收大小。
接收缓存47具有,将用于交付到应用程序处理部43的接收数据进行暂时保持的功能。接收缓存47能够储存最大RWIN_MAX的数据,根据应用程序处理部43的请求,将暂时保持在接收缓存47里的数据按照顺序,交付到应用程序处理部43。另外,接收缓存47在由于数据被交付到应用程序处理部43而使窗口大小增加时,将窗口大小已增加的情况通知给窗口更新通知生成部46。
窗口大小计算部48具有计算作为窗口大小通知给发送方装置38的值的功能。窗口大小计算部48根据由接收速率决定部50所指示的更新量(以下称做RWIN_Update),和被储存在上次RWIN存储部51中的上次已通知的窗口大小(RWIN_Prev),算出窗口大小。通过以下的公式来计算窗口大小。
窗口大小=RWIN_Prev+RWIN_Update…(公式1)
而且,考虑接收缓存47能够储存的数据的最大大小(RWIN_MAX),也可以通过以下的公式计算。
窗口大小=MIN(RWIN_Prev+RWIN_Update,RWIN_MAX)…(公式2)
设MIN(A,B)为A和B的最小值。
窗口更新计时器部49具有以规定间隔,指示窗口更新通知生成部46进行窗口更新通知包的发送的功能。而且,由接收速率决定部50来指示规定间隔。
接收速率决定部50具有,根据接收方装置31的TCP包的接收速率,来决定窗口大小计算部48的更新量和窗口更新计时器49的规定间隔的功能。接下来,举例说明更新量和规定间隔的决定方式。
例1:更新量和规定间隔可以根据FIFO36的容量和系统总线32的传送能力按照以下的公式计算。
更新量=FIFO36的容量…(公式3)
规定间隔=FIFO36的容量/系统总线32的传送能力…(公式4)
具体而言,在接收方装置31的FIFO36的容量是4KB、系统总线32的传送能力是40Mbps的情况下,更新量配合FIFO36的容量成为4KB,规定间隔为系统总线32传送4KB时所需要的时间0.8毫秒。而且,因为设规定间隔为0.8毫秒以上,所以数据传送量能够被控制在系统总线32的传送能力以下,也可以当作1毫秒。并且,在计算规定间隔的时候,除以的是系统总线32的传送能力,但是,也可以考虑CPU(Central ProcessingUnit)的处理能力,依据一个包的处理时间和系统总线的传送能力来计算规定间隔。
例2:更新量和规定间隔可以根据FIFO36的容量和应用程序所请求的比特率,按照以下的公式来计算。
更新量=FIFO36的容量…(公式5)
规定间隔=RTT/CEILING(((应用程序所需要的比特率×RTT)/8)/更新 量,1)…(公式6)
CEILING(A,B)输出将A以B为单位向上舍入的结果。
具体而言,接收方装置31的FIFO36的大小是4KB,在应用程序所请求的比特率为10Mbps、RTT为10毫秒的情况下,更新量配合FIFO36的大小成为4KB。并且,在这种情况下,因为应用程序所请求的比特率为10Mbps,所以在1RTT(10毫秒)中,需要应用程序接收12.5KB的数据。因此,如果考虑作为更新量以4KB递增的话,在1RTT中就需要3.125次,即需要更新4次。因而,规定间隔为RTT/4,即2.5毫秒。
例3:更新量和规定间隔可以根据在接收缓存47中能够储存的数据的最大容量RWIN_MAX和应用程序所请求的比特率,按照以下的公式来计算。
更新量=RWIN_MAX…(公式7)
规定间隔=RTT/CEILING(((应用程序所需要的比特率×RTT)/8)/RWIN_MAX,1)…(公式8)
具体而言,在接收缓存47中能够储存的数据的最大容量RWIN_MAXB为8KB、应用程序所需要的比特率为10Mbps、RTT为10毫秒的情况下,更新量配合RWIN_MAX称为8KB。并且,在这种情况下,因为应用程序所需要的比特率为10Mbps,所以在1RTT(10毫秒)中,需要应用程序接收12.5KB的数据。因此,如果考虑作为更新量以8KB递增的话,在1RTT中就需要1.5625次,即需要更新2次。因而,规定间隔为RTT/2,即5毫秒。
另外,也能够以例1至例3所示的公式为基础,将更新量以MSS为单位化零为整,并将规定间隔以毫秒或者几毫秒为单位向上舍入。
而且,接收速率决定部50在被设置了多个连接的情况下,处理部33为了实施另外的通信处理以外的处理,在处理能力降低了的情况等,配合接收方装置31的接收状况发生变化的情况,也可以具有将更新量和规定间隔进行动态改变的功能。
上次RWIN存储部51具有,将上次进行窗口更新通知之时所使用的 窗口大小(以下称做上次窗口大小)进行记录保持的功能。上次RWIN存储部51将记录保持的上次窗口大小交付到窗口大小计算部48,窗口大小计算部48接受算出的结果,并更新上次窗口大小再进行记录保持。
图10是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图10的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,将一个包的长度作为1、更新量作为4、更新间隔(上述的规定间隔)作为T毫秒来进行说明。并且,图中的P71(Ack=10,Win=4)表示ACK号码10及窗口大小4的ACK包,P81(Seq=10,11,12,13)表示序列号码10、11、12、13的数据包。
接收方装置31通过确立与发送方装置38的连接等,变成接收从发送方装置38发送的数据的状态。此时,接收方装置31将更新量4作为ACK包(也可以是窗口更新通知包)的窗口大小进行设定,并且将此ACK包(窗口更新通知包)发送给发送方装置38(P71)。接收了ACK包P71的发送方装置38,根据所接收的ACK包P71的窗口大小为4的情况,将序列号码10、11、12、13的四个数据包P81进行发送(P81)。
其次,接收方装置31在发送ACK包P71之后,在经过规定间隔的T毫秒的情况下,依照公式1,在上次通知的窗口大小4之上增加更新量4,将窗口更新通知包的窗口大小设定成8,并将此窗口更新通知包发送给发送方装置38(P72)。接收了ACK包P72的发送方装置38,根据所接收的ACK包P72的窗口大小为8的情况,能够将包含已经发送完毕的序列号码10、11、12、13的八个数据包进行发送。因此,发送方装置38将作为数据包P81的后续序列号码14、15、16、17的数据包P82进行发送。
之后,ACK包P73、P74也与上述同样地从接收方装置31被发送。而且,数据包P83、P84也与上述同样地从发送方装置38被发送。
此时,因为接收方装置31发送的ACK包的间隔为T毫秒,所以发送方装置38接收ACK包的间隔也成为T毫秒。并且,由于发送方装置38接收的ACK包的间隔是T毫秒,且依照每个更新量来增加窗口大小,所 以发送方装置38以T毫秒的间隔,将依照每个更新量的数据包进行发送。
因为发送方装置38以T毫秒的间隔发送数据包,所以接收方装置31变成以T毫秒的间隔按照每个更新量接收数据包。而且,因为此T毫秒是从(公式4)或者从(公式6)等计算出的数值,所以在此T毫秒之间,接收方装置31能够处理更新量大小的数据。因此,能够使接收处理在不达到极限的情况下进行接收处理。
如此在本实施例中,通过在接收方装置31,对从发送方装置38发送的发送数据的间隔和其大小进行控制,能够获取接收方装置31的最大限度的性能。而且,根据本发明,不依据数据包的接收,而可以随时开始对此发送数据的间隔和其大小的控制。并且,由于按照更新量的单位来控制发送数据量,所以减少了窗口更新通知包的生成次数,也使用同样的窗口更新通知包的ACK号码。其结果为,由于在一系列的窗口更新通知包里应该改变的参数只是窗口大小,所以能够减轻处理负荷。例如,RWIN_MAX为32、更新量为4、RTT为10毫秒的时候,本实施例中的窗口更新通知包的发送间隔为1.42毫秒。另一方面,在专利文献1中,由于使用按照每1MSS能够接收的可用缓存容量进行ACK分割、更新的方式,所以需要以0.32毫秒的间隔进行控制。因此,在本实施例中与以往的技术相比能够减轻处理负荷。并且,能够对从发送方装置38被发送的发送数据的间隔和其大小,按照适合接收方装置31的应用程序的接收速率的速率来进行控制,在接收缓存中,最多也只有更新量大小的数据逗留,存储器的使用效率也会提高。
(实施例2)
本实施例的通信装置(接收方装置)与在实施例1的图8中所示的结构大致相同,只有处理部不同。因此,在此省略有关处理部以外的组成部分的详细说明。
图11是在本实施例的接收方装置31中的、表示处理部的功能结构的一个例子的框图。本实施例的接收方装置31具备代替实施例1的处理部33的处理部33a。以下,对有关各组成部分的功能进行说明。而且,因为 本实施例的处理部33a具有针对实施例1的处理部33而附加的功能,所以只说明与实施例1有区别的部分。
处理部33a具备IP处理部61、TCP处理部62及应用程序处理部63。
而且,本实施例的接收方装置31的TCP处理部62具有:TCP包处理部64、接收缓存67、窗口大小计算部68、窗口更新计时器部69、接收速率决定部70、及上次RWIN存储部71。这里,接收缓存67、窗口大小计算部68及上次RWIN存储部71具有与实施例1的接收缓存47、窗口大小计算部48及上次RWIN存储部51同样的功能及结构。
TCP包处理部64具备ACK生成部65及窗口更新通知生成部66。这样的TCP包处理部64在具有实施例1中所示的TCP包处理部44的功能的同时,还具有在根据(公式1)将通知窗口大小进行更新的过程中,接收了来自发送方装置38的包的情况下,将停止窗口更新通知功能的情况通知给接收速率决定部70的功能。另外,窗口更新通知功能是指,如实施例1所示的、以规定间隔使窗口大小增加,再将表示被增加的窗口大小的窗口更新通知包发送给发送方装置38的功能。
窗口更新计时器部69在具有实施例1中所示的窗口更新计时器部49的功能的同时,还具有根据来自接收速率决定部70的停止通知停止计时器功能的功能。
接收速率决定部70在具有实施例1所示的接收速率决定部50的功能的同时,还具有在接收来自TCP包处理部64的停止通知的情况下,停止窗口更新计时器部69的功能和设更新量为0的功能。
图12是本实施例中表示在数据包和ACK包之间进行互相传递的序列图。在图12的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,将一个包的长度作为1、更新量作为4、更新间隔(上述的规定间隔)作为T毫秒来进行说明。并且,图中的P91(Ack=10,Win=4)表示ACK号码10及窗口大小4的ACK包,P101(Seq=10,11,12,13)表示序列号码10、11、12、13的数据包。
到接收方装置31发送ACK包P94为止,及到发送方装置38发送数据包P104为止,在接收方装置31及发送方装置38的数据收发处理与实施例1相同。因此,接收方装置31从发送ACK包P95的处理、即从经过1RTT后的处理起进行说明。
经过1RTT后,接收方装置31接收数据包P101。接收方装置31在接收数据包P101的情况下,针对数据包P101生成ACK包P95,并发送到发送方装置38。而且,接收速率决定部70在接收数据包P101的情况下,停止窗口更新计时器部69的窗口更新计时器,且将窗口大小计算部68的更新量设定为0。因此,发送ACK包P95的窗口大小变成上次RWIN存储部71所保持的窗口大小的数值,即变为16。
发送方装置38在接收此ACK包P95的情况下,能够从ACK号码14及窗口大小16起,将序列号码14以后的数据按照窗口大小16的大小发送。因此,发送方装置38发送序列号码14以后的尚未发送数据,即序列号码26、27、28、29的数据包P105。
其次,对有关在接收方装置31接收数据包P102时的处理进行说明。在接收数据包P102之时,窗口更新计时器处于停止状态,更新量变成0。因此,针对数据包P102的ACK包P96的窗口大小,变成上次RWIN存储部71所保持的窗口大小的数值,即变为16。而且,接收了此ACK包P96的发送方装置38,发送序列号码18以后的尚未发送数据,即序列号码30、31、32、33的数据包P106。以后,以同样的方式重复处理。
图13是在本实施例中的表示接收方装置31的工作流程图。
首先,接收方装置31确立与发送方装置38的连接,形成能够接收从发送方装置38发送的数据的状态。然后,接收方装置31开始起动窗口更新通知功能(步骤S400)。总之,接收方装置31生成表示ACK号码=N及窗口大小=更新量的ACK包或者窗口更新通知包,并发送到发送方装置38。另外,N是接收方装置31所请求的数据包的序列号码。而且,此时接收方装置31的窗口更新计时部49开始时间测量。
其次,接收方装置31判断是否从发送方装置38接收了数据包(步骤S402)。这里,当判断为从接收方装置38没有接收数据包之时(步骤S402的“否”),接收方装置31进一步判断是否已经经过了规定期间(即T毫秒)(步骤S404)。
在接收方装置31判断为已经经过T毫秒的情况下(步骤S404的“是”),生成表示ACK号码=N及窗口大小=上次的窗口大小+更新量的窗口更新通知包,并发送到发送方装置38(步骤S406)。另一方面,当判断为尚未经过T毫秒之时(步骤S404的“否”),或在步骤S406中窗口更新通知包的发送结束之时,接收方装置31再次执行从步骤S402起的处理。
而且,接收方装置31判断为在步骤S402中接收了数据包的情况下(步骤S402的“是”),则停止上述窗口更新通知功能(步骤S408)。即,窗口更新计时器部49停止时间测量,更新量被复位为0。并且,接收方装置31将作为针对接收了的、从发送方装置38被发送的数据包的确认应答,生成表示ACK号码=N+n及窗口大小=上次的窗口大小的ACK包,并发送到发送方装置38(步骤S410)。另外,n是在接收方装置31中被接收的数据包的数量。
然后,接收方装置31再次判断是否从接收方装置38接收了数据包(步骤S412)。其结果为,当判断为接收了数据包之时(步骤S412的“是”),接收方装置31重复执行从步骤S410起的处理;当判断为没有接收数据包之时(步骤S412的“否”),则结束来自发送方装置38的数据接收处理。
如此在本实施例中,在能够得到与实施例1同样的效果的同时,由于经过1RTT后接收速率决定部70将更新量置0,以停止窗口更新计时器,所以在接收数据后也能够将从发送方装置38发送的数据的速率保持在一定程度。
(实施例3)
本实施例的通信装置(接收方装置)与在实施例1的图8中所示的结构大致相同,只有处理部不同。因此,在此省略有关处理部以外的组成部分的详细说明。
图14是在本实施例的接收方装置31中的、表示处理部的功能结构的 一个例子的框图。本实施例的接收方装置31具备代替实施例1的处理部33的处理部33b。以下,对有关各组成部分的功能进行说明。而且,因为本实施例的处理部33b具有针对实施例2的处理部33a而附加的功能,所以只说明与实施例2有区别的部分。
处理部33b具备IP处理部81、TCP处理部82及应用程序处理部83。
而且,本实施例的接收方装置31的TCP处理部82具有:TCP包处理部84、接收缓存87、窗口大小计算部88、窗口更新计时器部89、接收速率决定部90、及上次RWIN存储部91。这里,接收缓存87及上次RWIN存储部91具有,与实施例1的接收缓存47及上次RWIN存储部51同样的功能及结构。
TCP包处理部84具备ACK生成部85及窗口更新通知生成部86。这样的TCP包处理部84在具有实施例2中所示的TCP包处理部64的功能的同时,具有在窗口更新通知功能停止的过程中,在接收来自发送方装置38的包的情况下,将重新开始窗口更新通知功能的情况通知给接收速率决定部90的功能。
窗口大小计算部88具有在实施例1及实施例2中所示的窗口大小计算部48、68的功能。并且,窗口大小计算部88在具有在一连串的数据接收里的数据总量由应用程序处理部83来通知的功能的情况下,使窗口大小减小的功能,该窗口大小为配合数据总量的数据接收结束的时刻由ACK包来通知的。
窗口更新计时器部89具有,实施例2所示的窗口更新计时器部69的功能和,在接受来自接收速率决定部90的重新开始窗口更新通知功能的通知的情况下,重新开始窗口更新通知功能的功能。
接收速率决定部90具有,实施例2所示的接收速率决定部70的功能和,在接受来自TCP包处理部84的窗口更新通知功能重新开始的通知的情况下,进行规定间隔和更新量的计算,并向窗口更新计时器部89发出窗口更新通知功能重新开始的通知的功能。
图15是本实施例中、表示在数据包和ACK包之间进行互相传递的序 列图。在图15的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,将一个包的长度作为1、更新量作为4、更新间隔(上述的规定间隔)作为T毫秒来进行说明。并且,图中的P111(Ack=6,Win=8)表示ACK号码6及窗口大小8的ACK包,P121(Seq=2,3,4,5)表示序列号码2、3、4、5的数据包。
发送方装置38在将数据包P121、P122进行发送的情况下,暂且结束数据传送。此后,在空出任意一段时间后,重新开始传送数据包P123。以下,对此时在ACK包和数据包之间的互相传递进行说明。
首先,对有关发送方装置38在数据包P122暂且结束传送的情况进行说明。
窗口大小计算部88从应用程序处理部83得到在一连串的数据接收里的数据总量的通知。因此,窗口大小计算部88配合数据总量的数据接收结束的时刻,使发送的ACK包的窗口大小减小。(公式9)表示在窗口大小计算部88的窗口大小计算公式。
窗口大小=MIN((总数据量-接收数据量)+更新量,上次RWIN存储部所保持的窗口大小)…(公式9)
即导出:窗口大小=MIN(剩余的接收数据量+更新量,上次RWIN存储部所保持的窗口大小)…(公式10)
而且,也可以为总数据量合起来的以下公式:
窗口大小=MIN(总数据量-接收数据量,上次RWIN存储部所保持的窗口大小)…(公式11)
在(公式11)的情况下,来自发送方装置38的数据发送被重新开始之时,从对接收方装置31的接收缓存里是否存在可用空间进行确认的核实包开始数据发送。
在图15中,发送方装置38发送数据包P121。接收了数据包P121的接收方装置31生成与数据包P121对应的ACK包P111,并将其发送。此时接收方装置31所发送的数据包根据(公式9),被设定为窗口大小8。其次,发送方装置38发送数据包P122。接收了数据包P122的接收方装置 31生成与数据包P122对应的ACK包P112,并将其发送。此时接收方装置31所发送的数据包根据(公式9),被设定为窗口大小4。这样,配合剩余接收数据量以使窗口大小减小。
其次,对发送方装置38重新开始数据发送以后,即发送了数据包P123以后的情况进行说明。
发送方装置38发送数据包P123,重新开始数据发送。此时,依据接收方装置31在上次发送的ACK包P112的窗口大小是4的情况,发送方装置38会发送序列号码10、11、12、13和窗口大小的量的数据包。这样,在暂且停止发送之时,由于已经使窗口大小减小,所以在数据发送重新开始之时,防止了发送数据突发到达的情况。
其次,接收方装置31在接收由发送方装置38重新开始发送的数据包P123的情况下,生成与接收的数据包P123对应的ACK包P113,并将其发送。此后,接收方装置31将数据传送已经重新开始的情况通知给接收速率决定部90。接受了通知的接收速率决定部90和实施例1同样,决定更新量和规定间隔,并催促窗口更新计时器部89以使窗口更新计时器重新开始计时。其结果为,接收方装置31发送ACK包P113之后,在经过规定间隔的T毫秒的情况下,依照(公式1),在上次通知的窗口大小4之上增加更新量4,将窗口更新通知包的窗口大小设定成8,并将此窗口更新通知包发送给发送方装置38(P114)。并且,接收方装置31在规定间隔的T毫秒间隔中,将窗口更新通知包P115、P116进行发送。因此,发送方装置38在规定间隔的T毫秒间隔中,将数据包P124、P125、P126进行发送。
如此在本实施例中能够得到与实施例1及实施例2同样的效果。并且,在本实施例中,即使在数据传送暂且停止的时候,由于使窗口大小减小并且窗口更新通知功能重新开始,所以能够对来自发送方装置的发送暂且停止后的重新开始的发送数据的发送速率进行控制。
(实施例4)
本实施例的通信装置(接收方装置)与在实施例1的图8中所示的结构 大致相同,只有处理部不同。因此,在此省略有关处理部以外的组成部分的详细说明。
而且,在本实施例中的接收方装置31的处理部,与实施例2的图11所示的处理部33a大致上有同样的结构。因此,有关本实施例的处理部,为了明确其与实施例2的区别而使用图11来进行以下说明。
本实施例中的TCP包处理部64在具有实施例2中所示的功能的同时,具有在窗口更新通知功能停止的过程中,检测包损失,在确认了来自发送方装置38的损失了的包的重新发送的情况下,将重新开始窗口更新通知功能的情况通知给接收速率决定部70的功能。
本实施例中的窗口更新计时器部89在具有实施例2所示的功能的同时,具有在接受来自接收速率决定部70的重新开始窗口更新通知功能的通知的情况下,重新开始窗口更新计时器功能的功能。
接收速率决定部70具有实施例2中所示的功能。并且,接收速率决定部70具有,在接受来自TCP包处理部64的窗口更新通知功能重新开始的通知的情况下,进行规定间隔和更新量的计算,并向窗口更新计时器部69发出窗口更新通知功能重新开始的通知的功能和,将在上次RWIN存储部71中记录的上次窗口大小值重置为初始值,例如将其返回到0的功能。
上次RWIN存储部71具有实施例2中所示的功能和通过接收速率决定部70的工作,使储存的上次窗口大小值被初始化的功能。
图16是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图16的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,为了简化说明,将一个包的长度作为1、更新量作为1、更新间隔(上述的规定间隔)作为T毫秒来进行说明。并且,图中的P131(Ack=11,Win=6)表示ACK号码11及窗口大小6的ACK包,P151(Seq=10)表示序列号码10的数据包。
接收方装置31在窗口更新通知功能停止的状态下,以固定的间隔接受从发送方装置38发送的数据包。此时,以数据包P152发生了包损失的情 况来说明。
接收方装置31由于数据包P153的到达而发现发生了包损失。为此,接收方装置31发送ACK号码11的ACK包P133。此后,接收方装置31同样地接收包损失以后的数据包P154、P155、P156,因为发生了包损失,所以发送ACK号码11的ACK包P134、P135、P136。此时,发送方装置38在连续四次接收重复的ACK号码的ACK包的情况下,则检测出网络上发生了包损失,不等到超时就立即重新发送数据包P158(TCP高速重新发送功能)。到此为止是在以往的TCP中也被装配的功能。
其次,对依据TCP高速重新发送功能的、数据包P158被重新发送处理以后的情况进行说明。
在接收方装置31接收被重新发送了的数据包P158的情况下,TCP包处理部64将发生包损失并接收了重新发送包的情况通知到接收速率决定部70。被通知接收了重新发送包的情况的接收速率决定部70,将上次RWIN存储部71的值初始化,并催促窗口更新计时器部69起动窗口更新计时器,设定更新量为1,重新开始窗口更新通知功能。此后,接收方装置31生成ACK包P138并将其发送。此时生成的ACK包P138依据现在接收的序列号码16,设定ACK号码17,根据在上次RWIN存储部71中记录的值和更新量,窗口大小1被设定。接收了这个ACK包P138的发送方装置31,根据被通知的窗口大小1,发送后续的序列号码17的数据包P159。
其次,接收方装置31在发送ACK包P138之后,在经过规定间隔的T毫秒的情况下,依照(公式1),在上次通知的窗口大小1之上增加更新量1,将窗口更新通知包的窗口大小设定成2,并将此窗口更新通知包发送给发送方装置38(P139)。接收了ACK包P139的发送方装置38,根据所接收的ACK包P139的窗口大小为2的情况,能够将包含已经发送完毕的序列号码17的两个数据包进行发送。因此,发送方装置38将数据包P159的后续序列号码18的数据包P160进行发送。以后,接收方装置31和实施例1同样,以T毫秒间隔进行窗口更新处理,并以T毫秒间隔接收数据 包。
如此在本实施例中能够得到与实施例1及实施例2同样的效果。并且,本实施例在发生包损失后,通过使窗口更新通知功能重新开始,对有关发送方装置的重新发送数据也能够进行发送速率的控制。而且,通过与实施例3进行组合,也能够享受在实施例3中得到的效果。
(实施例5)
本实施例的通信装置(接收方装置)与在实施例1的图8中所表示的结构大致相同,只有处理部不同。因此,在此省略有关处理部以外的组成部分的详细说明。
图17是在本实施例的接收方装置31中的、表示处理部的功能结构的一个例子的框图。本实施例的接收方装置31具备代替实施例1的处理部33的处理部33c。以下,对有关各组成部分的功能进行说明。而且,因为本实施例的处理部33c具有针对实施例2的处理部33a而附加的功能,所以只说明与实施例2有区别的部分。
处理部33c具备IP处理部101、TCP处理部102及应用程序处理部103。
而且,本实施例的接收方装置31的TCP处理部102具有:TCP包处理部104、接收缓存107、窗口大小计算部108、窗口更新计时器部109、接收速率决定部110、上次RWIN存储部111、及ACK延迟部112。这里,接收缓存107、窗口大小计算部108、窗口更新计时部109、及上次RWIN存储部111具有与实施例2的接收缓存67、窗口大小计算部68、窗口更新计时器部69及上次RWIN存储部71同样的功能及结构。
TCP包处理部104具备ACK生成部105及窗口更新通知生成部106。窗口更新通知生成部106具有与实施例2的窗口更新通知生成部66同样的功能及结构。
ACK生成部105与实施例1至4的ACK生成部同样,根据接收了的TCP包的序列号码,来决定ACK号码以生成ACK包。在ACK包中,从窗口大小计算部108得到的、目前能够接收的可用空间,即窗口大小也被 设定。并且,本实施例的ACK生成部105将生成的ACK包交付到ACK延迟部112。被交付了的ACK包在此后被发送。
接收速率决定部110在具有与实施例2的接收速率决定部70同样的功能的同时,具有对ACK延迟部112指定ACK包延迟时间和此ACK量的功能。ACK包延迟时间及ACK量由以下的公式来决定。
ACK量=更新量…(公式12)
ACK包延迟时间=更新间隔(上述的规定间隔)…(公式13)
而且,ACK量及ACK包延迟时间与计算更新量及更新间隔的公式一样,可以依据FIFO36的容量或系统总线32的传送能力来计算,或者依据应用程序所请求的比特率来计算。
ACK延迟部112具有在发送之前将生成的ACK包暂时保持,并使发送延迟的功能。ACK延迟时间根据接收速率决定部110而被决定。
图18是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图18的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,将一个包的长度作为1、更新量作为4、更新间隔(上述的规定间隔)作为T毫秒来进行说明。并且,图中的P175(Ack=14,Win=16)表示ACK号码14、窗口大小16的ACK包,P183(Seq=18,19,20,21)表示序列号码18、19、20、21的数据包。
接收方装置31与实施例2同样,在窗口更新通知功能开始后,因为经过1RTT,并接收数据包P181,所以窗口更新通知功能处于停止的状态。
接收方装置31的ACK生成部105在接收数据包P181的情况下,生成其ACK包并交付到ACK延迟部112。接受了ACK包的ACK延迟部112,求出在上次发送ACK包(或者,窗口更新通知包)的时间上,加上ACK包延迟时间而算出的ACK发送时间,如果现在时间超过ACK延迟时间并且ACK号码比上次ACK包增加了ACK量大小,则立即发送ACK包。在图18中,数据包P181被接收的时候,因为从上次ACK包发送时间以来已经经过ACK包延迟时间,所以ACK包P175立即被发送。
这里,设发送方装置38所发送的数据包P182为由于网络37的状况变化,比通常都早点被接收。接收方装置31的ACK生成部105生成针对接收了的数据包P182的ACK包,并交付到ACK延迟部112。接受了ACK包的ACK延迟部112,因为在上次ACK包P175的发送时间上加上ACK延迟时间而算出的ACK发送时间的结果为,ACK发送时间不足现在时间,所以不立即进行ACK包P176的发送。此后,ACK延迟部112在现在时间达到ACK发送时间的情况下,发送保存在ACK延迟部112中的ACK包P176。
图19是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图19的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,将一个包的长度作为1、更新量作为4、更新间隔(上述的规定间隔)作为T毫秒来进行说明。
接收方装置31与实施例2同样,在窗口更新通知功能开始后,因为经过1RTT,并接收数据包P201,所以窗口更新通知功能处于停止的状态。
接收方装置31的ACK生成部105在接收数据包P201的情况下,生成此ACK包并交付到ACK延迟部112。接受了ACK包的ACK延迟部112,求出在上次发送ACK包(或者,窗口更新通知包)的时间上,加上ACK包延迟时间而算出的ACK发送时间,如果现在时间超过ACK延迟时间并且ACK号码比上次ACK包增加了ACK量大小,则立即发送ACK包。在图19中,数据包P201被接收的时候,因为从上次ACK包发送时间以来已经经过ACK包延迟时间,所以ACK包P195立即被发送。
这里,设发送方装置38所发送的数据包P202为由于网络37的状况变化,与通常相比发生迟延才被接收。接收方装置31的ACK生成部105生成针对接收了的数据包P202的ACK包,并交付到ACK延迟部112。接受了ACK包的ACK延迟部112,因为在上次ACK包P195的发送时间上加上ACK延迟时间而算出的ACK发送时间的结果为,现在时间已经过了ACK发送时间,所以立即进行ACK包P196的发送。即,在图19 中,由于从上次ACK包P195的发送时间开始早已超过ACK包延迟时间,因此ACK包P196立即被发送。
并且,接收方装置31接收发送方装置38所发送的数据包P203。接收方装置31生成针对接收了的数据包P203的ACK包,并交付到ACK延迟部112。接受了ACK包的ACK延迟部112,因为在上次ACK包P196的发送时间上加上ACK延迟时间而算出的ACK发送时间的结果为,ACK发送时间不足现在时间,所以不立即进行ACK包P197的发送。此后,ACK延迟部112在现在时间达到ACK发送时间的情况下,发送保存在ACK延迟部112中的ACK包P197。以后也同样,ACK延迟部112确认ACK发送时间,并进行ACK包P198、P199的发送。然后,在发送ACK包P200的时候,因为数据包的到达间隔返回到了规定间隔,所以变为ACK包立即被发送的状态。
如此在本实施例中能够得到与实施例1及实施例2同样的效果。并且,在本实施例中,由于网络的波动,数据包的到达间隔即使产生了变化,通过控制ACK包的发送间隔,也能够进行发送方装置的发送速率控制。而且,通过与实施例3或者实施例4进行组合,也能够享受在实施例3或者实施例4中得到的效果。
(实施例6)
本实施例的通信装置(接收方装置)与在实施例1的图8中所表示的结构大致相同,只有处理部不同。因此,在此省略有关处理部以外的组成部分的详细说明。
而且,在本实施例中的接收方装置31的处理部,与实施例5的图17所示的处理部33c大致上有同样的结构。因此,有关本实施例的处理部,为了明确其与实施例5的区别而使用图17来进行以下说明。
图17表示以本发明的接收方装置31的TCP处理部为中心的处理结构例。以下,对有关各处理部的功能进行说明。另外,实施例5和结构例大致相同,在功能上只有少许的区别。在对本实施例进行说明时,只说明其与实施例5有区别的部分。
本实施例中的接收速率决定部110在具有实施例5所示的功能的同时,具有在接受接收速率改变的请求的情况下,更新ACK延迟时间和ACK量,并通知到ACK延迟部112的功能。
本实施例中的ACK延迟部112在具有实施例5所示的功能的同时,具有根据接收速率改变请求来接受由接收速率决定部110所决定的、ACK延迟时间和ACK量,并反映到所发送的ACK包里的功能。
图20是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图20的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,将从窗口更新通知开始后到经过1RTT为止的一个包的长度作为1、更新量作为4、更新间隔(上述的规定间隔)作为T毫秒来进行说明。并且,图中的P211(Ack=14,Win=16)表示ACK号码14及窗口大小16的ACK包,P222(Seq=18,19,20,21)表示序列号码18、19、20、21的数据包。
接收方装置31接收数据包P221,并发送ACK包P212。到此为止,接收方装置31进行与实施例5同样的数据收发处理。此后,设接收方装置31为到图中的“接收速率改变”的时间就要改变接收速率。设在本实施例中,要将接收间隔(上述的规定间隔)改变为2倍的2T毫秒。此速率改变请求被通知到接收速率决定部110。接受了接收速率的改变请求的接收速率决定部110因为要将接收间隔变为2倍,所以对ACK延迟部112发出将ACK包延迟时间设为2倍的指示。
此后,接收方装置31在接收数据包P222的情况下,ACK生成部105即生成ACK包,并交付到ACK延迟部112。接受了ACK包的ACK延迟部112在上次的ACK发送时间上加上ACK包延迟时间,以求出ACK包发送时间。此时被算出的ACK发送时间比没有接到接收速率改变请求而算出的ACK发送时间要早。因此,在数据包P222被接收的时候,由于现在时间尚未达到ACK发送时间,所以接收方装置31的ACK延迟部112不立即进行ACK发送。
此后,接收方装置31在接收数据包P223的情况下,ACK生成部105 即生成ACK包,并交付到ACK延迟部112。接受了ACK包的ACK延迟部112在上次的ACK发送时间上加上ACK包延迟时间,以求出ACK包发送时间。其结果为,在数据包P223被接收的时候,由于现在时间达到ACK发送时间,所以ACK延迟部112立即进行ACK发送。而且,此时因为ACK延迟部112保存有针对以前的数据包P222的ACK包,所以要将其保存的数据量4从窗口大小里减去,变为窗口大小12来进行ACK包P213的发送。以后同样,接收方装置31进行数据包P224、P225的接收处理,并进行ACK包P214的发送。这样,发送方装置38就能够将发送的数据包的发送间隔变为两倍。
图21是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图21的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,将从窗口更新通知开始后到经过1RTT为止的一个包的长度作为1、更新量作为4、更新间隔(上述的规定间隔)作为T毫秒来进行说明。
接收方装置31接收数据包P241,并发送ACK包P232。到此为止,接收方装置31进行与实施例5同样的数据收发处理。此后,设接收方装置31为在图中的“接收速率改变”的时间就要改变接收速率。设在本实施例中,要将更新量改变为二分之一。此速率改变请求被通知到接收速率决定部110。接受了接收速率改变请求的接收速率决定部110因为要将更新量变为二分之一,所以对ACK延迟部112发出设更新量为二分之一的指示。即,在本实施例中更新量变为2。
此后,接收方装置31在接收数据包P242的情况下,ACK生成部105即生成ACK包,并交付到ACK延迟部112。接受了ACK包的ACK延迟部112在上次的ACK发送时间上加上ACK包延迟时间,以求出ACK包发送时间。因为此时被算出的ACK发送时间在数据包P242被接收的时候,已经达到现在时间,所以ACK延迟部112立即发送ACK包P233。但是,按照接收速率改变请求,ACK延迟部112的更新量为二分之一。因此,现在将要发送的ACK包的ACK量是序列号码18、19、20、21的四份,由 于更新量是2,所以ACK延迟部112依照(公式14),将窗口大小设定为14并发送ACK包P233。
窗口大小=上次RWIN存储部111所储存的窗口大小-(ACK量-更新量)…(公式14)
同样,接收方装置31在接收数据包P243、P244、P245的情况下,一边以2为单位来减少窗口大小,一边发送ACK包P234、P235、P236。
此后,接收方装置31接收从发送方装置38发送的数据包P246。这里,数据包P246是序列号码34、35的两份数据,成为ACK量=2。因此,接收方装置31依照(公式14),发送和上次的窗口大小相同的显示为8的窗口大小的ACK包P237。这样,发送方装置38就能够将发送的数据包的发送量变为二分之一。
如此在本实施例中能够得到与实施例1、实施例2及实施例5同样的效果。并且,在本实施例中,对应接收方装置的接收情况的变化,通过对ACK发送间隔或窗口大小进行控制,发送方装置能够将所发送的数据包的发送速率进行动态改变。而且,通过与实施例3或者实施例4进行组合,也能够享受在实施例3或者实施例4中得到的效果。
(实施例7)
本实施例的通信装置(接收方装置)与在实施例1的图8中所示的结构大致相同,只有处理部不同。因此,在此省略有关处理部以外的组成部分的详细说明。
图22是在本实施例的接收方装置31中的、表示处理部的功能结构的一个例子的框图。本实施例的接收方装置31具备代替实施例1的处理部33的处理部33d。以下,对有关各组成部分的功能进行说明。而且,因为本实施例的处理部33d具有针对实施例1的处理部33而附加的功能,所以只说明与实施例1有区别的部分。
处理部33d具备IP处理部121、TCP处理部122及应用程序处理部123。
而且,本实施例的接收方装置31的TCP处理部122具有:TCP包处 理部124、接收缓存127、窗口大小计算部128、窗口更新计时器部129、接收速率决定部130、及上次RWIN存储部131。这里,接收缓存127、窗口大小计算部128、窗口更新计时部129、及上次RWIN存储部131具有与实施例1的接收缓存47、窗口大小计算部48、窗口更新计时器部49及上次RWIN存储部51同样的功能及结构。
TCP包处理部124具备ACK生成部125及窗口更新通知生成部126。TCP包处理部124在具有与实施例1所示的TCP包处理部44的功能的同时,还具有在从接收速率决定部130得到更新量的通知,且连续接收数据包达到更新量的时候,将接收数据包已经达到更新量的情况通知给接收速率决定部130的功能。
接收速率决定部130具有实施例1中所示的接收速率决定部50的功能。并且,接收速率决定部130具有将更新量通知给TCP包处理部124的功能和,当连续接收数据包达到更新量的时候,将接收数据包已经达到更新量的情况的通知从TCP包处理部124接收的功能。还有,接收速率决定部130在接收已经达到更新量的通知的情况下,使用(公式3)至(公式8)中的任意一个方式算出更新量和规定间隔,并将计算值传达到窗口大小计算部128和窗口更新计时器部129。
图23是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图23的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,将一个包的长度作为1、更新量作为4、更新间隔(上述的规定间隔)作为T毫秒来进行说明。并且,图中的P251(Ack=2,Win=4)表示ACK号码2及窗口大小4的ACK包,P261(Seq=1)表示序列号码1的数据包。
发送方装置38具有将发送数据量逐渐增加的所谓慢起动的功能。因此,发送方装置38发送的发送数据包的数量按照每1RTT增加一个包(P261)、两个包(P262)、四个包(P263)。到数据包P262被接收为止,因为发送方装置38连续发送的数据包尚未达到更新量,所以在接收方装置31不进行窗口更新通知功能。
此后,接收方装置31接收数据包P263。接收了数据包P263的接收方装置31生成针对数据包P263的ACK包P253,并将其发送。同时,在接收方装置31中,TCP包处理部124将已经达到更新量的情况通知给接收速率决定部130。被通知了达到更新量的情况的接收速率决定部130将更新量(在本实施例为4)通知给窗口大小计算部128,并催促窗口更新计时部129,以启动窗口更新计时器,且开始窗口更新通知功能。接收了ACK包P253的发送方装置38,根据所接收的ACK包P253的窗口大小为4的情况,将后续的序列号码8、9、10、11进行发送。
其次,开始了窗口更新通知功能的接收方装置31在发送ACK包P253之后,在经过规定间隔的T毫秒的情况下,依照(公式1),在上次通知的窗口大小4之上增加更新量4,将窗口更新通知包的窗口大小设定成8,并将此窗口更新通知包发送给发送方装置38(P254)。接收了ACK包P254的发送方装置38,根据所接收的ACK包P254的窗口大小为8的情况,能够将包含已经发送完毕的序列号码8、9、10、11的八个数据包进行发送。因此,发送方装置38将作为数据包P263的后续序列号码12、13、14、15的数据包P264进行发送。
如此在本实施例中,在能够得到和实施例1同样的效果的同时,即使在发送方装置进行慢起动的情况下,也能够通过接收方装置来控制发送方装置的发送速率。而且,即使是以下图24所示的数据收发处理,也能够得到与上述同样的效果。
图24是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图24的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,将一个包的长度作为1、更新量作为4、更新间隔(上述的规定间隔)作为T毫秒来进行说明。
此时,接收方装置31和发送方装置38的数据收发处理,到数据包P343被接收为止,进行与图23所示的处理同样的处理。其次,在接收方装置31中,在数据包P343被接收的情况下,TCP包处理部124将已经达到更 新量的情况通知给接收速率决定部130。被通知了达到更新量的情况的接收速率决定部130将更新量(在本实施例为4)通知给窗口大小计算部128,并催促窗口更新计时部129,以启动窗口更新计时器,且开始窗口更新通知功能。
接下来,开始了窗口更新通知功能的接收方装置31,按照以下的公式14进行窗口更新。
窗口大小=上次通知的窗口大小+更新量-ACK号码增加量…(公式14)
而且,在本实施例中,将上次通知的窗口大小作为4、更新量作为4、ACK号码增加量作为1来进行说明。
接收了数据包P343的接收方装置31,通过窗口更新通知功能接收数据包后,将ACK包P333发送到发送方装置。此时,ACK包P333的ACK号码依据ACK号码增加量1而变成5,窗口大小根据(公式14)而变成7。接收了ACK包P333的发送方装置38根据所接收的ACK包P333的窗口大小为7、ACK号码为5的情况,将5以后的未发送序列、即序列号码8、9、10、11的数据包P344进行发送。
接下来,通过窗口更新通知功能,接收方装置31在发送ACK包P333之后,在经过规定间隔的T毫秒的情况下,按照(公式14),在上次通知的窗口大小7之上加上更新容量4,并根据ACK号码增加量1来算出窗口大小10。接收方装置31将以算出的窗口大小10来设定的ACK包P334,通知到发送方装置38。接收了ACK包P334的发送方装置38根据所接收的ACK包P334的窗口大小为10、ACK号码为6的情况,将在ACK号码为6以后的序列中未发送序列、即序列号码12、13、14、15的数据包P345进行发送。
如此在本实施例中,在能够得到和实施例1同样的效果的同时,即使在发送方装置进行慢起动的情况下,也能够通过接收方装置来控制发送方装置的发送速率。而且,通过与实施例2、实施例3、或者实施例4进行组合,也能够享受在各自的实施例中所得到的效果。
另外,在本实施例中,当从发送方装置38连续发送的数据包达到更新量之时,使窗口更新通知功能开始,但是,当经过了预先规定的时间之时,或当从发送方面装置38所发送的全部数据包的数量达到预先规定的数量之时,也可以使窗口更新通知功能开始。
(实施例8)
本实施例的通信装置(接收方装置)与在实施例1的图8中所示的结构大致相同,只有处理部不同。因此,在此省略有关处理部以外的组成部分的详细说明。
图25是在本实施例的接收方装置31中的、表示处理部的功能结构的一个例子的框图。本实施例的接收方装置31具备代替实施例1的处理部33的处理部33e。
处理部33e具备IP处理部141、TCP处理部142及应用程序处理部143。而且,在本实施例中,TCP处理部142作为在处理部33e被执行的程序而进行说明,也可以是安装在LSI等的情况。另外,图中的实线表示收发包的数据流,虚线表示与控制信息的互相传递有关的流。
接收方装置31的TCP处理部142具有:TCP包处理部144、接收缓存147、窗口大小计算部148、及上次RWIN存储部149。
TCP包处理部144具有TCP包的收发处理的功能。TCP包处理部144对接收了的包的应用程序进行确认,并为了将此包提交给应用程序而将其储存在接收缓存147中。并且,TCP包处理部144具有构筑TCP包、再将其交付到IP处理部141、且作为TCP/IP包进行发送的功能。另外,TCP包处理部144包括ACK生成部145、窗口更新通知生成部146及包损失检测部150。
ACK生成部145根据接收了的TCP包的序列号码,来决定ACK号码以生成ACK包。在ACK包中,从窗口大小计算部148得到的、目前能够接收的可用空间,即窗口大小也被设定。
窗口更新通知生成部146在接收缓存147的可用空间发生增加的时候,生成窗口更新通知包。而且,窗口更新通知生成部146将从窗口大小 计算部148得到的窗口大小设定在此窗口更新通知包中。
包损失检测部150具有检测TCP包的遗漏或损失的功能。而且,包损失检测部150具有将发生了损失的情况通知给窗口大小计算部148的功能。
接收缓存147具有将用于向应用程序处理部143交付的接收数据进行暂时保持的功能。接收缓存147能够储存最大RWIN_MAX的数据,根据应用程序处理部143的请求,将暂时保持在接收缓存147里的数据按照顺序,交付到应用程序处理部143。另外,接收缓存147在由于数据交付到应用程序处理部143而使窗口大小增加时,将窗口大小已增加的情况通知给窗口更新通知生成部146。
窗口大小计算部148具有计算作为窗口大小通知给发送方装置38的值的功能。即,在本实施例中的窗口大小计算部148根据通过包损失检测部150而被通知的包损失来计算窗口大小。窗口大小通过以下的公式被算出。
窗口大小=上次通知的窗口大小-上次通知的窗口大小中损失了的数据量…(公式15)
而且,在规定时间H内未检测出包损失的情况下,也可以使用以下的公式进行计算。
窗口大小=上次通知的窗口大小+更新量…(公式16)
并且,更新量可以是1MSS,也可以是多个MSS。
上次RWIN存储部149具有,将上次进行窗口更新通知之时所使用的窗口大小(以下称做上次窗口大小)进行记录保持的功能。上次RWIN存储部149将记录保持的上次窗口大小交付到窗口大小计算部148,窗口大小计算部148接受算出的结果,并更新上次窗口大小再进行记录保持。
图26是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图26的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,为了简化说明,将一个包的长度作为1、更新量作为2、规定时间作为H毫秒来 进行说明。并且,图中的P351(Ack=1,Win=8)表示ACK号码1及窗口大小8的ACK包,P362(Seq=8)表示序列号码8的数据包。
接收方装置31通过确立与发送方装置38的连接等,变成接收从发送方装置38发送的数据的状态。此时,接收方装置31将窗口大小为8的情况通知给发送方装置38(P351)。发送方装置38根据窗口大小8,将数据包P361、P362发送到接收方装置31。但是,由于此时网络37处于拥挤状态,或者变换装置的能力不足等原因,设数据包P362为损失了的情况。数据包P362未到达的接收方装置31,发送针对已到达的序列号码为止的ACK包P352。接收了ACK包P352的发送方装置38,将后续的序列号码,即数据包P363进行发送。
接收了数据包P363的接收方装置31检测出损失了序列号码8的情况,将与上次发送的ACK包P352同样的ACK包(以下称做重复ACK包)P353,发送所接收的包中的一部分,即(序列号码9至15的包)的包数。而且,在本实施例中有7个重复ACK包P353被发送。接收了重复ACK包的发送方装置38在得知序列号码8损失了的情况下,通过高速重新发送功能重新发送序列号码8的数据包P364。
接收了被重新发送的数据包P364的接收方装置31,根据(公式15)使窗口大小减少,作为窗口大小7来发送ACK包P354。接收了ACK包P354的发送方装置38,依据被设定在此ACK包里的窗口大小为7的情况,发送7个包大小的数据包P365。
总之,如果在ACK包P354中窗口大小被设定为8的情况下,设发送方装置38与在发送数据包P361、P362的时候同样,再次试图将具有8个包的数据包发送到接收方装置31。其结果为,增大再次发生包损失的可能性。
然而,在本实施例中,因为在ACK包P354中窗口大小被设定为7,所以能够防止再次发生包损失。
图27是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图27的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。而且,为了简化说明,将一个包的长度作为1、更新量作为2、规定时间作为H毫秒来进行说明。
接收方装置31通过确立与发送方装置38的连接等,变成接收从发送方装置38发送的数据的状态。此时,接收方装置31将窗口大小为6的情况通知给发送方装置38(P371)。发送方装置38根据窗口大小6,将数据包P381发送到接收方装置31。接收了数据包P381的接收方装置31将表示ACK序列号码7及窗口大小6的ACK包P372发送给发送方装置38。如此的接收方装置31和发送方装置38的数据收发处理,暂时会被连续地反复进行。
并且,接收方装置31在开始数据包的接收并经过规定时间H的情况下,根据(公式16)使窗口大小只增加更新量,将窗口大小作为8来通知(P373)。因此,发送方装置38发送对应窗口大小8的数据包P382。
总之,如果在规定时间H之间没有发生包损失,则发送方装置38能够比在抑制发生包损失的状态中,发送更多的包的可能性增大。因此,在本实施例中,如果在规定时间H之间没有发生包损失,由于窗口大小的设定较大,所以能够提高数据传送效率。
如此在本实施例中,通过使窗口大小配合包损失状况进行动态变化,能够防止连续的包损失的情况。而且,在检测出包损失没有发生的情况下,通过使窗口大小增加,而能够实现更高效的数据传送。
(实施例9)
本实施例的通信装置(接收方装置)与在实施例1的图8中所示的结构大致相同,只有处理部不同。因此,在此省略有关处理部以外的组成部分的详细说明。
图28是在本实施例的接收方装置31中的、表示处理部的功能结构的一个例子的框图。本实施例的接收方装置31具备代替实施例1的处理部33的处理部33f。
处理部33f具备IP处理部161、TCP处理部162及应用程序处理部 163。而且,在本实施例中,TCP处理部162作为在处理部33f被执行的程序而进行说明,也可以是安装在LSI等的情况。另外,图中的实线表示收发包的数据流,虚线表示与控制信息的互相传递有关的流。
接收方装置31的TCP处理部162具有:TCP包处理部164、接收缓存167及窗口大小计算部168。而且,接收缓存167具有与实施例1的接收缓存47同样的功能及结构。
TCP包处理部164具有TCP包的收发处理的功能。TCP包处理部164对接收了的包的应用程序进行确认,并为了将此包提交给应用程序而将其储存在接收缓存167中。并且,TCP包处理部164具有构筑TCP包、再将其交付到IP处理部161、且作为TCP/IP包进行发送的功能。另外,TCP包处理部164包括ACK生成部165、重复ACK生成部166及包遗漏检测部169。
ACK生成部165根据接收了的TCP包的序列号码,来决定ACK号码以生成ACK包。在ACK包中,从窗口大小计算部168得到的、目前能够接收的可用空间,即窗口大小也被设定。
重复ACK生成部166具有,在从包遗漏检测部169得到接收包发生了遗漏的通知的情况下,生成重复ACK包并将其发送的功能。在重复ACK包中,设定有从窗口大小计算部168得到的窗口大小。
包遗漏检测部169具有检测TCP包的遗漏或损失的功能。而且,包遗漏检测部169会将发生了包遗漏的情况通知给重复ACK生成部166。
窗口大小计算部168具有,依据接收缓存167的可用空间计算窗口大小,并通知给ACK生成部165或重复ACK生成部166的功能。
图29是本实施例中、表示在数据包和ACK包之间进行互相传递的序列图。在图29的例子中,虚线表示由接收方装置31发送的ACK包或者窗口更新通知包,实线表示由发送方装置38发送的数据包。
发送方装置38在从接收方装置31接收ACK包P391的情况下,将数据包P401、P402、P403传送给接收方装置31。这里,设在发送方装置38所发送的数据包P401、P402、P403之中,数据包P402为没有被接收方装置31所接收的情况。
此时,接收方装置31依据数据包P403的到达,来检测包的遗漏。检测出包的遗漏的接收方装置31会立即生成规定数的ACK包P392,并发送到发送方装置38。
接收了规定数的ACK包P392的发送方装置38,通过高速重新发送功能,立即重新发送数据包P404。
如此在本实施例中,在检测包遗漏之后,通过将同样的ACK包以规定数发送到发送方装置,而可以迅速引发发送方装置的高速重新发送功能,并且能够快速进行包遗漏的修复。
(实施例10)
以下参照附图来对本实施例进行说明。
图30是涉及本发明的实施例的网络的结构例及通信装置的结构例的框图。在图30中,通信装置200A通过网络3A,与通信装置100A进行通信。通信装置100A及通信装置200A是具有与网络3A进行有线连接或者无线连接通信功能的装置,例如,具备Ethernet(注册商标)接口的装置(例如PC(Personal Computer)或能够使用网络通信的家电设备等)。网络3A包含有线网络或者无线网络,可以列举如互联网等公共网络。
本实施例中,设想通信装置100A和通信装置200A分别在各自之间确立TCP的连接,从通信装置200A向通信装置100A发送数据。在此设想之上,在通过TCP的连接而进行数据发送的关系中,将数据发送方的通信装置200A称为发送方装置,将数据接收方的通信装置100A称为接收方装置。例如,设想依据应用程序进行工作的FTP客户、即接收方装置,从FTP(File Transfer Protocol:文件传送协议)服务器、即发送方装置(例如PC)上下载文件的情况;或者设想依据处理电子邮件的应用程序进行工作的接收方装置,从POP(Post Office Protocol:邮电所协议)服务器、即发送装置接收电子邮件的情况等。
通信装置100A具备作为处理部的CPU101A、存储部102A、系统总线103A、及通信部105A。
通信部105A是连接在系统总线103A上的硬件。此通信部105A具有将通过CPU101A而被交付的数据发送到网络3A的功能和,从网络3A接收数据再交付到CPU101A的功能。
而且,此通信部105A具备将从网络3A接收的数据暂时保持的接收用FIFO存储器151A和,将从CPU101A被交付的数据进行暂时保持的发送用FIFO存储器152A。并且,通信部105A具备,在从网络3A接收的数据未能够全部储存在接收用FIFO存储器151A而溢出的情况下,检测此数据损失的数据损失检测部150A。
另外,数据损失检测部150A也可以只有在损失了的包的协议及端口号码与目前正在通信的协议及端口号码相一致的情况下,将发生溢出的情况通知给CPU101A。并且,接收用FIFO存储器151A和发送用FIFO存储器152A,也可以在发送和接收时共享。
CPU101A具有将储存在通信部105A的接收用FIFO存储器151A中的数据移动到存储部102A(读出)的功能和,将储存在存储部102A的数据移动到通信部105A的发送用FIFO存储器152A(写入)的功能。而且,CPU101A还进行对储存在存储部102A中的数据执行数据的分析或数据的编制处理等包括TCP在内的协议处理。另外,CPU101A具有一边使用存储部102A一边执行通信应用程序,或者一边按照需要执行其他程序的功能。
并且,在从存储部102A到通信部105A的发送用FIFO存储器152A、或者从通信部105A的接收用FIFO存储器151A到存储部102A的数据传送中,也存在通信装置100A、200A另外具备DMA控制器,不使用CPU,而使用DMA(Direct Memory Access:直接存储器存取)控制器进行数据的移动的情况。还有,各个协议处理也可以不通过CPU101A来执行,而是在另外的硬件上被各自执行。
图31是在通信装置100A的表示CPU101A的功能结构的框图。
在图31中表示的功能结构可以作为在图30中所示的CPU101A上工作的软件来实现。另外,虽然图31的框图是作为接收方装置,以涉及本发 明的TCP数据的接收处理为中心而记载的,但是,通信装置100A也可以具备进行TCP数据的发送处理的功能部。而且,通信装置200A可以是以往的通信装置,也可以是具有适用于本发明的接收处理的功能部的通信装置。以下,在记述各功能部的说明时,只对涉及本发明的接收处理进行详细的记述,而省略涉及发送处理的功能及工作的说明。并且,也省略对有关用于实现与本发明没有直接关系的TCP通信的其他的构成的说明。
而且,在图31中使用几种指示线来表示数据的传输。实线表示包或者数据的传输的数据流,虚线表示控制信号(通知或者系数)的传输的控制流。
在图31中,通信装置100A的CPU101A作为处理接收或者发送包的包处理部的详细构成,具有API(Application Programming Interface:应用软件编程接口)部1100、TCP处理部1200、IP处理部1300、IF处理部1400、及MAC处理部1500。并且,TCP处理部1200具有接收缓存1240、Window控制部1250、WinUpdate生成部1260、DupAck生成部1270、Ack生成部1280、TCP发送部1220、TCP接收部1210、TCP损失检测部1215、及DupAck管理部1230。另外还有,MAC处理部1500具有损失通知部5000、包复制部7000、MAC发送部1520、及MAC接收部1510。
API部1100与TCP处理部1200、例如与FTP等应用程序之间进行数据的传递,并在此处理结束时进行通知。API部1100按照来自应用程序的请求,向TCP处理部1200请求数据的传递,再将由TCP处理部1200传递的数据按照应用程序能够处理的需要进行转换或复制,并将此处理结束的情况通知给TCP处理部1200。
TCP处理部1200将从IP处理部1300接受的TCP包,转换成向API部1100交付的数据。TCP处理部1200将包含在从IP处理部1300接受的一个或多个TCP包里的数据,从TCP包中提取并将其保持,按照来自API部1100的数据的传递请求,交付该数据。而且,TCP处理部1200生成针对从IP处理部1300接受的TCP包的Ack,并交付到IP处理部1300。另外,在本实施例中,将ACK作为上述实施例1至9的ACK或 者ACK包来进行说明。
IP处理部1300从IF处理部1400接受IP包,并从所接受的IP包中提取TCP包,再将其交付到TCP处理部1200。而且,IP处理部1300在从TCP处理部1200接受的TCP包里追加IP首部以构筑IP包,并将其交付到IF处理部1400。
IF处理部1400从MAC处理部1500接受MAC帧,并从所接受的MAC帧里提取IP包,在将其交付到IP处理部1300。并且,IF处理部1400在从IP处理部1300接受的IP包里追加MAC首部以构筑MAC帧,并将其交付到MAC处理部1500。
MAC处理部1500将在图30中所示的从通信部105A接受的数据交付到IF处理部1400。这个处理是从图30的通信部105A的接收用FIFO存储器151A,向图30的存储部102A交付(读出)数据的处理。而且,MAC处理部1500将从IF处理部1400接受的MAC帧交付到通信部105A。这个处理是从图30的存储部102A,向通信部105A的发送用FIFO存储器152A交付(写入)数据的处理。
以下,有关上述TCP处理部1200及MAC处理部1500的更加详细的结构,使用图31来进行说明。
TCP处理部1200的接收缓存1240是管理从TCP接收部1210接受的数据的缓存区域。所管理的数据本身被储存在图30的存储部102A中。接收缓存1240具有将所管理的数据交付到API部1100,并开放保持了交付结束的数据的缓存区域的功能。而且,对于来自Window控制部1250的可以使用的缓存大小的咨询,将可以使用的缓存大小传达到Window控制部1250的功能。
Window控制部1250依据向接收缓存1240咨询而得到的可以使用的缓存大小,算出Win并将其保持。并且,在本实施例中,将Win作为实施例1至9的窗口大小来进行说明。而且,Window控制部1250对于来自DupAck管理部1230及Ack生成部1280的Win的咨询,将所管理的Win交付到各个部。还有,Window控制部1250在收到来自API部1100的应 用程序处理结束的通知的情况下,依据向接收缓存1240咨询而得到的可以使用的缓存大小来算出Win,并将算出的Win交付到DupAck管理部1230。
WinUpdate生成部1260在从DupAck管理部1230接受了Win的情况下,生成WindowUpdate(将增加了能够接收的Win的情况通知给发送方装置的Ack,以后称做WinUpdate)并交付到TCP发送部1220。
DupAck生成部1270从DupAck管理部1230接受DupAck信息,并根据所接受的DupAck信息生成DupAck(Duplicate acknowledgement:即时应答确认)且交付到TCP发送部1220。而且,DupAck包含上述实施例1至9的作为ACK号码的序列号码(以下称做Seq)和Win。另外,DupAck或者DupAck包相当于上述实施例1至9的重复ACK。
Ack生成部1280在从TCP接收部1210接受了Seq的情况下,根据向Window控制部1250咨询而得到的Win和从TCP接收部1210接受了的Seq生成Ack,并交付到TCP发送部1220。
而且,在本实施例中,DupAck生成部1270及Ack生成部1280各自作为第一包生成单元而被构成,该第一包生成单元生成确认应答包、即DupAck或者Ack。
TCP发送部1220设定,从DupAck管理部1230或者Ack生成部1280接受的TCP包(DupAck或者Ack)所必要的TCP首部信息,并将此TCP包交付到IP处理部1300。
TCP接收部1210具备TCP损失检测部1215,用于检查TCP包的Seq是否按顺序排列。TCP处理部1200在从IP处理部1300接受的TCP包的Seq是按顺序排列的情况下(TCP损失检测部1215没有检测TCP包的损失的情况),执行从TCP包提取数据的处理,并交付到接收缓存1240。而且,TCP接收部1210在Seq是按顺序排列的情况下,将下面的Seq交付到Ack生成部1280。并且,交付到Ack生成部1280的下面的Seq的功能,不是每回发生也可以。在这种情况下,对Ack生成部1280的通知是按照多次里有一次的比例被通知的,或是依据Delayed Ack算法,使系 统计时器经过规定时间后进行通知。
TCP损失检测部1215检查从TCP接收部1210接受的TCP包的Seq,在Seq不是按顺序排列的情况下,则将所需的Seq交付到DupAck管理部。
DupAck管理部1230将从TCP损失检测部1215接受的Seq和,通过向Window控制部1250咨询而得到的Win,作为DupAck信息进行保持。并且,DupAck管理部1230将DupAck信息交付到DupAck生成部1270,并将其交付次数作为DupAck发送数来计数。
而且,DupAck管理部1230在从Window控制部1250接受了Win的情况下,根据来自损失通知部5000的包损失信息,且依据保持的DupAck发送数算出不足规定数的DupAck复制数。在其结果是1以上的情况下,DupAck管理部1230在将从Window控制部1250接受的Win交付到WinUpdate生成部1260之前,将保持的DupAck信息(Seq及Win)交付到DupAck生成部1270。并且,DupAck管理部1230针对包复制部7000的咨询,通知算出的DupAck复制数。另外,在本实施例中,关于DupAck管理部1230算出的DupAck复制数,以包为单位的管理为例来进行说明。
还有,也可以把DupAck复制数不作为发送的包单位,而是作为一个,例如TCP的连接单位或整个通信装置来进行管理。
并且,在DupAck管理部1230将DupAck复制数通知到包复制部7000的情况下,消去从包损失通知部5000接受的包损失信息,进一步将DupAck复制数及DupAck发送数复位到初始值。作为DupAck复制数的初始值,以1为例来进行说明。并且,作为DupAck发送数的初始值,以0为例来进行说明。
MAC处理部1500具有MAC接收部1510、MAC发送部1520、及损失通知部5000。以下表示各自的详细情况的说明。
MAC接收部1510将从图30的通信部105A的接收用FIFO存储器151A读出MAC帧(P200),交付到IF处理部1400。即,设MAC接收部1510为,试图通过CPU101A将图30的接收用FIFO存储器151A的数 据移动到存储部102A。
MAC发送部1520具有包复制部7000。MAC发送部1520将从IF处理部1400接受的MAC帧,只按照包复制部7000所指示的复制数,存入图30的通信部105A的发送用FIFO存储器152A中(P100)。即,设MAC发送部1520为,试图从图30的CPU101A将数据移动到发送用FIFO存储器152A。因此,MAC发送部1520复制DupAck并将其存入发送用FIFO存储器152A。
包复制部7000向DupAck管理部1230进行咨询,并根据咨询而得到的DupAck复制数(N个),对MAC发送部1520发出成为对象的MAC帧的N次的发送指示。而且,在图30的通信部105A具有只将MAC帧复制成DupAck复制数(N个)的功能的情况下,包复制部7000也可以把成为对象的MAC帧的数据的移动作为1次,进行N次复制并只发出发送的指示。
而且,在本实施例中,MAC发送部1520和包复制部7000作为第二包生成单元被构成,该第二包生成单元生成作为数据请求包的DupAck。
损失通知部5000接受来自图30的数据损失检测部150A的包损失通知(E150),并将包损失信息交付到DupAck管理部1230。而且,在包损失通知(E150)中包括IP地址和协议、端口号码的情况下,损失通知部5000向DupAck管理部1230交付作为包损失信息的IP地址、协议、及端口号码。其结果为,DupAck管理部1230根据从损失通知部5000取得的IP地址或端口号码,确定发送方装置200A,该发送方装置200A用于催促重新发送损失的包。即,DupAck管理部1230具有装置确定单元。
以下,有关在涉及本实施例的通信装置之间的通信序列,以通信装置100A作为接收方装置、通信装置200A作为发送方装置进行工作为例,使用图32来进行说明。
图32是在本施实例中的通信装置之间的通信序列的示意图。并且,接收方装置100A的性能较低(例如CPU101A的性能为133MHz)。而且,为了简化说明,将储存在一个包内的数据长度,即一个包长度(LEN)做为1KByte,Seq或Win的单位和数值也与其相配合。而且,图32表示接收 方装置100A的Win变少的情况。还有,在图32中省略发送方装置200A和接收方装置100A的TCP连接时的协议设立,和接收方装置100A的Win达到由多变少的状态(Win=4,参考图32的W11)的通信序列。
如图32所示,接收方装置100A对于Seq=1的数据(P21)的接收,将Ack(P12)发送到发送方装置200A。在此Ack中包含作为参数的接着请求的包的序列号码(Num=2)和,接收方装置100A的能够接收的信息量(Win=3)。Win的值为3(W12)是因为,在针对Seq=1的数据的在应用程序中的接收处理未结束,能够接收的数据量减少的缘故。在图32的例子中,Seq=2的数据(P22)从接收方装置100A的接收处理中到TCP(通信协议的传输层)的处理中消失(发生包消失)。因此,接收方装置100A不送回针对Seq=2(P22)的Ack。
其次,接收方装置100A针对Seq=3、4(P23、P24)的数据的接收,将Ack发送到发送方装置。此Ack(P13、P14)的哪个的参数都成为Num=2及Win=3。这是因为,接收方装置100A在Seq=1的数据之后接收了Seq=3及Seq=4的数据,所以检测出Seq=2的数据不足的情况。接收方装置100A在接收Seq=1包之时,就已经发送请求Ack的Seq=2的包。因此,此Ack(P13、P14)成为传达Seq=2的数据没有到达的情况的DupAck。此时,这些DupAck(P13、P14)的Win与针对Seq=1的包的Ack(P12)的Win一样。这是由于针对Seq=1的数据的应用程序的接收处理尚未结束而造成的。
因为接收方装置100A的CPU101A的速度较低,所以针对Seq=1的数据的应用程序的接收处理在接收方装置100A发送了第二个DupAck之后结束。应用程序的接收处理结束之后,接收方装置100A对发送方装置200A发送传达Win恢复了的情况的WinUpdate(Num=2及Win=4)(P16)。这里,接收方装置100A在即将发送此WinUpdate之前,复制已经发送的DupAck(P14),并将此复制的DupAck(P15)发送到发送方装置200A。发送方装置200A接收第三个DupAck(P15),并高速重新发送Seq=2的重新发送数据(P25)。
图33是在接收方装置100A中的处理序列的例子的示意图。具体而言,图33表示从接收方装置100A接收Seq=1(P21)的数据,到发送WinUpdate(P16)为止的处理序列。使用图33的处理序列和图30及用图31的接收方装置100A的框图,对在本实施例中的接收方装置100A里的处理进行说明。而且,在图33中,用虚线包围的“通信部”表示图30的通信部105A,用虚线包围的“MAC”表示图31的MAC处理部1500,用虚线包围的“IF”表示图31的IF处理部1400,用虚线包围的“IP”表示图31的IP处理部1300。并且,在图33中,用虚线包围的“TCP”表示图31的TCP处理部1200,用虚线包围的“API”表示图31的API部1100,用虚线包围的“应用程序”表示图31的应用程序。
首先,按照图33的处理流程,对接收方装置100A从接收Seq=1(P21)的包开始到发送Ack(P12)为止的处理序列(P21、P211、P121、及P12)进行说明。
如图33所示,从通信装置(发送方装置)200A被发送的Seq=1的包(P21),通过网络3A经通信装置(接收方装置)100A的通信部105A进行接收处理。储存在通信部105A的接收用FIFO存储器151A的Seq=1的包(P21),通过CPU101A,从接收用FIFO存储器151A被存储部102A读出。而且,在从接收用FIFO存储器151A向存储部102A的移动当中,接收方装置100A另外具备DMA控制器,也可以不通过CPU101A,而通过DMA控制器来移动此包。
通过MAC处理部1500的MAC接收部1510从通信部105A的接收用FIFO存储器151A读出的Seq=1的MAC帧(P21),经IF处理部1400及IP处理部1300被非包化,并被交付到TCP接收部1210(数据流P211)。
TCP接收部1210进行Seq=1的TCP包的TCP首部的分析处理,并结束非包化处理。此时,在TCP损失检测部1215中,因为在Seq=1的包(P21)接收处理之前没有发生包损失,所以Seq=1的包被判断为按顺序接收的数据,并作为接收数据交付到接收缓存1240及DupAck管理部1230。这个被交付的接收数据通过API部1100交付到应用程序中。
而且,因为在TCP损失检测部1215中,已经确认了是按顺序接收的数据,所以TCP接收部1210为了把已经接收了该数据的情况通知给发送方装置200A,将下面的Seq,即Seq=2交付到Ack生成部1280。从TCP接收部1210接收了Seq的Ack生成部1280,通过Window控制部1250,向接收缓存1240咨询目前能够接收的Win。Ack生成部1280根据咨询的结果,即Win=3,和从TCP接收部1210接收的Seq,针对Seq=1的包(P21)生成表示Num=2及Win=3的TCP包,并交付到TCP发送部1220。
TCP发送部1220针对此TCP包构筑TCP首部,IP处理部1300及IF处理部1400针对被此TCP首部构筑处理的TCP包进行包构筑。被进行包构筑的表示Num=2及Win=3的MAC帧,通过MAC处理部1500的MAC发送部1520,作为包被存入通信部105A的发送用FIFO存储器152A中(数据流P121)。
如此,被存入通信部105A的发送用FIFO存储器的数据(MAC帧),作为Seq=1的包(P21)的Ack(P12)通过网络3A被发送到发送方装置200A。
其次,按照图33的处理流程,对接收方装置100A从接收Seq=2(P22)开始的处理序列(P22及E100)进行说明。
从通信装置(发送方装置)200A被发送的Seq=2的包(P22),通过网络3A经通信装置(接收方装置)100A的通信部105A进行接收处理。但是,因为CPU101A的速度较低,所以在通信部105A的接收用FIFO存储器151A中充满了已经接收的包,而发生溢出。其结果为,Seq=2的包(P22)未被储存在接收用FIFO存储器151A中。
因为Seq=2的包发生了溢出,所以数据损失检测部150A对CPU101A发出发生了溢出的通知(控制流E100)。即,损失通知部5000接受包损失的通知,并向TCP处理部1200的DupAck管理部1230交付包损失信息。DupAck管理部1230将接受的包损失信息进行保持。
其次,按照图33的处理流程,对接收方装置100A从接收Seq=3及Seq=4的包(P23、P24)开始到发送Ack(P13、P14)为止的处理序列(P231、 P131、P241、P141)进行说明。因为针对P23及P24的数据的处理与针对P21的数据的处理一样,所以在这里省略对那些处理的说明。而且,针对P13及P14的数据的处理,因为与针对P12的数据的处理一样,所以在这里省略对那些处理的说明。
通过MAC处理部1500的MAC接收部1510被读出的Seq=3的包(P23),经IF处理部1400及IP处理部1300被非包化,并被交付到TCP接收部1210(数据流P231)。TCP接收部1210对接受了的TCP包的TCP首部进行分析处理,并结束非包化处理。此时,由于Seq=2的包(P22)还没有到达,Seq=3的TCP包在TCP损失检测部1215中,被判断为不是按顺序接受的接收数据。TCP损失检测部1215将应该按照顺序到达的序列号码(Seq=2),交付到DupAck管理部1230。
接受了Seq=2的DupAck管理部1230,通过Window控制部1250,向接收缓存1240咨询目前能够接收的Win,并接受Win=3。DupAck管理部1230将从TCP损失检测部1215接受的Seq=2和,向Window控制部1250咨询而得到的Win=3作为DupAck信息进行保持,并将DupAck信息交付到DupAck生成部1270。还有,DupAck管理部1230将DupAck发送数计数为“1”。DupAck生成部1270依据所接受的DupAck信息(Win及Seq),生成表示Num=2及Win=3的DupAck,并将生成的DupAck交付到TCP发送部1220。
DupAck(Num=2及Win=3)从TCP发送部1220经过IP处理部1300及IF处理部1400,进行包构筑(数据流P131)。进行了包构筑的包(MAC帧),被输出到MAC处理部1500的包复制部7000。此时,包复制部7000向DupAck管理部1230咨询复制数,因为此复制数为“1”,所以对MAC处理部1500不发出包复制的指示。其结果为,MAC发送部1520在通信部105A的发送用FIFO存储器152A中只存入一个包。
与数据流P231同样,依据MAC处理部1500的MAC接收部1510所读出的Seq=4的包(P24),从TCP处理部1200的DupAck管理部1230直到DupAck生成部1270(数据流P241)。DupAck管理部1230判断目前所保持的DupAck信息的Seq=2和,从TCP损失检测部1215接受的Seq是同样的,在同样的情况下,DupAck管理部1230将管理的DupAck的发送数计数为“2”。
与数据流P131同样,DupAck(P14)从TCP发送部1220到MAC处理部1500的包复制部7000为止,依据MAC发送部1520被存入通信部105A的FIFO存储器152A(数据流P141)。
其次,按照图33的处理流程,对从依据Seq=1(P21)的数据的应用程序的处理结束,到开始DupAck的复制为止的处理序列(P212及P213)进行说明。
在发送方装置200A中,从接收来自接收方装置100A的Ack(P12)之后,Win的状态(图32所示的W12)没有改变。在W12的状态中,不能重新发送下面的包(Seq=5)。在此之间,在接收方装置100A中,依据来自应用程序的接收请求,接收缓存1240及DupAck管理部1230通过API部1100将所接收的数据交付到应用程序中(数据流P212)。
API部1100在向应用程序交付数据结束的情况下,将接收结束的情况通知给Window控制部1250(数据流P213)。
其次,对按照图33的处理流程,DupAck被进行包构筑,并在MAC处理部1500中DupAck被复制的处理序列(P151)进行说明。
从API部1100接受了接收结束的通知的Window控制部1250,向接收缓存1240咨询缓存的可用空间,并根据得到的缓存可用空间的信息算出Win=4。将算出的Win交付到DupAck管理部1230。
接受了Win的DupAck管理部1230根据在控制流E100中所保持的包损失信息,使用DupAck发送数“2”和规定的数值“3”,依据DupAck复制数计算方法算出DupAck复制数。此时的计算结果是“1”,此数值被保持在DupAck管理部1230。关于DupAck复制数的计算方法稍后进行说明。并且,DupAck管理部将保持的DupAck信息(Seq=2及Win=3)交付到DupAck生成部1270。
DupAck生成部1270依据所接受的DupAck信息,生成 DupAck(Num=2及Win=3)并交付到TCP发送部1220。
被交付到TCP发送部1220的表示Num=2及Win=3的TCP包(DupAck),经过IP处理部1300及IF处理部1400,进行包构筑(数据流P151)。进行了包构筑的DupAck包(MAC帧),被输出到MAC处理部1500的包复制部7000。此时包复制部7000对DupAck管理部1230进行咨询。包复制部7000依据向DupAck管理部1230咨询而得到的DupAck复制数“1”,对MAC发送部1520发出在通信部105A的发送用FIFO存储器152A中存入一个包的指示。因此,MAC发送部1520将一个DupAck包存入发送用FIFO存储器152A中。
在本实施例中,MAC发送部1520因为DupAck复制数是“1”,所以对通信部105A的发送用FIFO存储器152A只进行了一次DupAck包的写入,但是,在DupAck复制数是N(N≥2)的情况下,因为将同样的东西写入N回,所以进行N个DupAck包的发送。
被写入通信部105A的发送用FIFO存储器152A的包通过网络3A,作为DupAck包(P15)从通信部105A被发送到发送方装置200A。
其次,按照图33的处理流程,对在TCP处理部1200中生成的WinUpdate被进行包构筑,且被发送的处理序列(P161、P16)进行说明。
DupAck管理部1230将从Window控制部1250接受的Win=4交付到WinUpdate生成部1260。WinUpdate生成部1260生成WinUpdate,并交付到TCP发送部1220。被交付到TCP发送部1220的WinUpdate,经过IP处理部1300及IF处理部1400,进行包构筑(数据流P161)。被进行包构筑的WinUpdate包(MAC帧),从MAC发送部1520被交付到通信部105A。
并且,通信部105A通过网络3A,将此WinUpdate(P16)发送到发送方装置200A。
DupAck管理部1230在复制的DupAck包(P15)的发送之后,在控制流E100中消去从损失通知部5000被交付并保持的包损失信息,且将DupAck复制数初始化为“1”。
并且,DupAck管理部1230由于接收包损失序列的包,因此消去DupAck管理部1230所储存的DupAck信息(Seq及Win),使DupAck发送数为“0”、DupAck复制数为“0”。
另外,关于包损失信息的消去,即使在DupAck管理部1230没有复制DupAck的情况下,也可以在从损失通知部5000接受包损失信息并经过规定时间之后(例如1秒钟以后),消去此包损失信息。
而且,也可以在从损失通知部5000接受包损失信息之后PPS(PacketPer Sec)变低的情况下,执行包损失信息的消去。即,DupAck管理部1230具有复位单元。
并且,在从损失通知部5000接受包损失信息之后,包复制部7000先对发送的包数量进行管理,在确定的包数量被发送的情况下,也可以执行包损失信息的消去。
这里,使用图34,对关于在本实施例中,通过TCP处理部1200的DupAck管理部1230的DupAck复制数计算方法的算法进行说明。
图34是在本实施例中,表示DupAck复制数计算方法的算法的流程图。
DupAck管理部1230在从Window控制部1250接受Win更新的通知的情况下,对所保持的DupAck发送数是否为1以上且不足N进行检查(步骤S100)。并且,DupAck管理部1230通过损失通知部5000进行损失通知,并检查包损失信息是否被记录(步骤S102)。
即,在步骤S100中,DupAck管理部1230在自己管理的DupAck发送数是0以下或者是(N+1)以上的情况下(步骤S100的“否”),设DupAck复制数为“0”(步骤S104)。另一方面,在保持的DupAck发送数是1以上且不足N的情况下(步骤S100的“是”),DupAck管理部1230执行步骤S102的处理。另外,N是对发送方装置使之执行重新发送的所必要的DupAck的数量(规定数或者必要数)。
在步骤S102中,在来自损失通知部5000的包损失信息被记录的情况下(步骤S102的“是”),DupAck管理部1230使用公式“N-DupAck 发送数”算出DupAck复制数(步骤S106)。另一方面,在包损失信息没有被记录的情况下(步骤S102的“否”),DupAck管理部1230设DupAck复制数为“0”(步骤S104)。
例如,在本实施例中,在上述DupAck复制数计算方法的算法的开始之时,DupAck管理部1230从DupAck发送数“2”和损失通知部5000接受并保持(记录)包损失信息。因此,在步骤S100中,因为DupAck发送数是“2”,所以DupAck管理部1230执行步骤S102的处理。并且,在步骤S102中,因为DupAck管理部1230保持着包损失信息,DupAck复制数依据N=3及DupAck发送数“2”来算出。
因此,依据“DupAck复制数=N-DupAck发送数”,DupAck复制数变成“1”。
而且,上述N最好是发送方装置200A激活高速重新发送的数值。并且,在本实施例中,作为一个例子将N作为3,但是,作为避免DupAck在网络的包损失的条件,也可以设为3以上。尤其是网络的质量不好、在路径上DupAck容易消失的情况下,大的值有效。但是,因为所谓这个值大,就会牵涉到增加网络的通信量的情况,所以不希望无谓地增大此值。最好是3,即使大也最好是4。
如此在本实施例中,由于进行以上的处理而具有以下的效果:使发送方装置200A启动高速重新发送,并控制由于TCP的重新发送而产生的吞吐量降低的效果;只有在接收方装置100A里的包损失的情况下,使发送方装置200A启动高速重新发送的效果;不使网络处于负荷过大状态的效果;控制由于复制DupAck而产生的不必要的通信量的效果;控制DupAck发送所需要的接收方装置100A的CPU的消费的效果;和不发送出错的DupAck的效果。
(变形例1)
在此,对关于上述实施例10中的第一变形例进行说明。
在上述实施例10中,接收方装置100A检测在通信部105A的数据损失,而涉及本变形例的接收方装置100A检测在IP处理部1300的数据损 失。
并且,关于本变形例,只对有关与上述实施例10不共通的部分进行说明。
图35是在上述施实例10的第一变形例的网络结构例及通信装置的结构例的框图。
通信部105A是连接在系统总线103A上的硬件,不具备与上述实施例10的通信部105A一样的数据损失检测部150A。此通信部105A具有将通过CPU101A而被交付的数据发送到网络3A的功能和,从网络3A将接收数据接收的功能。而且,通信部105A具备将从网络3A接收的数据进行暂时保持的接收用FIFO存储器151A和,将从CPU101A被交付的数据进行暂时保持的发送用FIFO存储器152A。
使用图36对关于涉及本变形例的通过CPU101A的程序而被实现的功能结构进行说明。
图36是在接收方装置100A的表示CPU101A的功能结构的框图。并且在图36中,实线表示数据的传输的数据流,虚线表示控制信号的传输的控制流。作为对接收方装置100A的接收或者发送包进行处理的包处理部的详细构成,接收方装置100A的CPU101A具备:API部1100、TCP处理部1200、IP处理部1300、及MAC处理部1500。以下表示图36的各个功能部的说明。有关API部1100及TCP处理部1200,由于与上述实施例10的功能完全相同,所以省略对其的说明。
涉及本变形例的MAC处理部1500与在上述实施例10的MAC处理部1500不同,不具备损失通知部5000,只具备MAC接收部1510及MAC发送部1520。此MAC接收部1510及MAC发送部1520具有与上述实施例10同样的功能。
IP处理部1300与上述实施例10的IP处理部1300同样,从IF处理部1400接受IP包,并从所接受的IP包中提取TCP包,再将其交付到TCP处理部1200。而且,IP处理部1300在从TCP处理部1200接受的TCP包里追加IP首部以构筑IP包,并将其交付到IF处理部1400。这样 的IP处理部1300与上述实施例10的IP处理部1300不同,具备接收用FIFO队列1310和数据损失检测部150A和损失通知部5000。
接收用FIFO队列1310是将从IF处理部1400交付的数据进行暂时储存的区域。这个区域里被分配了存储部102A的区域之中的一部分,接收用FIFO队列1310具有管理在此区域中被储存的数据的功能。即,接收用FIFO队列1310,以从IF处理部1400接收的数据按照接收的顺序让IP处理部1300处理(First-In First-Out:先进先出)的方式进行管理。
数据损失检测部150A在接收用FIFO队列1310中检测发生了接收溢出的情况,并将发生了损失的情况,向损失通知部5000发送包损失通知(E150)。
损失通知部5000从数据损失检测部150A接受包损失通知(E150),并将通知发生了损失的情况的包损失信息,交付到TCP处理部1200的DupAck管理部1230。另外,在包损失通知(E150)里包含IP地址、协议或端口号码的情况下,损失通知部5000将包含IP地址、协议及端口号码的包损失信息交付到DupAck管理部1230。
图37是在涉及本变形例的接收方装置100A中的处理序列的例子的示意图。即,图37表示从接收方装置100A接收Seq=1(P21)的数据,到发送WinUpdate(P16)为止的处理序列。而且,在图37中,用虚线包围的“通信部”表示图35的通信部105A,用虚线包围的“MAC”表示图36的MAC处理部1500,用虚线包围的“IF”表示图36的IF处理部1400,用虚线包围的“IP”表示图36的IP处理部1300。还有,在图37中,用虚线包围的“TCP”表示图36的TCP处理部1200,用虚线包围的“API”表示图36的API部1100,用虚线包围的“应用程序”表示图36的应用程序。
将图37所示的处理序列与图33所示的处理序列相比较,只有针对Seq=2的包(P22)的在接收方装置100A的包损失检测的接收处理序列不同。以下,只对有关此接收处理序列进行说明。
按照图37的处理流程,说明由接收方装置100A对Seq=2(P22)的包 的处理序列(P22、P221、E150)。
从通信装置(发送方装置)200A被发送的Seq=2的包(P22),通过网络3A经通信装置(接收方装置)100A的通信部105A进行接收处理。
MAC处理部1500的MAC接收部1510将由通信部105A的接收用FIFO存储器151A读出的包(P22)进行接受。被读出的Seq=2的包(P22)通过IF处理部1400,被交付到IP处理部1300的接收用FIFO队列1310(数据流P221)。
在此,从IF处理部1400向IP处理部1300的接收用FIFO队列1310交付IP包的处理的速度或量,超出在IP处理部1300中从IP包提取TCP包再将此TCP包交付到TCP处理部1200的处理的速度或量,在接收用FIFO队列1310中发生溢出。数据损失检测部150A向损失通知部5000发出发生损失的通知(E150)。损失通知部5000接受在接收用FIFO队列1310发生溢出的包损失通知,对TCP处理部1200的DupAck管理部1230交付包损失信息。
另外,在本变形例中,对作为在IP处理部1300里具有接收用FIFO队列1310的情况进行了说明,但是,在IF处理部1400里具有同样的接收用FIFO队列的情况下,也可以在IF处理部1400里设置数据损失检测部及损失通知部。而且,对损失了的数据进行检查,只有在存在特定的协议(例如,IPv4,IPv6)的情况下发出通知。
并且,在数据损失检测部150A中,对损失了的数据进行检查,只有在存在特定的协议(例如TCP)的情况下发出此损失的通知。
而且,在数据损失检测部150A中,也可以将所损失数据的地址或端口号码附加在包损失通知上。还有,在DupAck管理部1230中,也可以根据所接受的IP地址或端口号码来进行损失的判断。
如此在本变形例中,由于进行以上的处理而具有以下的效果:使发送方装置200A启动高速重新发送,并控制由于TCP的重新发送而产生的吞吐量降低的效果;只有是在接收方装置100A里的确定的TCP包的包损失的情况下,使发送方装置200A启动高速重新发送的效果;不使网络处于 负荷过大状态的效果;控制由于复制DupAck而产生的不必要的通信量的效果和;不发送出错的DupAck的效果。
(变形例2)
在此,对关于上述实施例10中的第二变形例进行说明。
在上述实施例10中,于MAC处理部1500里复制了DupAck,而本变形例则是在TCP处理部1200里复制DupAck。
以下,关于本变形例,只对有关与上述实施例10不共通的部分进行说明。
图38是在上述实施例10中涉及第二变形例的CPU101A的功能结构的框图。实线表示数据的传输的数据流,虚线表示控制信号的传输的控制流。作为对接收方装置100A的接收或者发送包进行处理的包处理部的详细构成,接收方装置100A的CPU101A具备:API部1100、TCP处理部1200、IP处理部1300、及MAC处理部1500。以下表示图38的各个功能部的说明。并且,有关API部1100、IP处理部1300、及IF处理部1400,由于与上述实施例10的功能完全相同,所以省略对其的说明。
涉及本变形例的TCP处理部1200中的、具备包复制部7000的TCP发送部1220具有特性。
TCP发送部1220在从Ack生成部1280、WinUpdate生成部1260、及DupAck生成部1270接受的TCP包(Ack、WinUpdate、及DupAck)中设定必要的TCP首部信息,并将此被设定了TCP首部信息的TCP包交付到IP处理部1300。而且,TCP发送部1220将包复制部7000所复制的DupAck交付到IP处理部1300。
包复制部7000根据向DupAck管理部1230咨询而得到的DupAck复制数,只对此DupAck复制数复制DupAck,并指示TCP发送部1220将复制的DupAck交付到IP处理部1300。
并且,在本变形例中,此包复制部7000作为第二包生成单元而被构成,该第二包生成单元生成作为数据请求包的DupAck。
MAC处理部1500与在上述实施例10中的MAC处理部1500不同, 不具备包复制部7000。MAC接收部1510、MAC发送部1520、及损失通知部5000具有与上述实施例10同样的功能。
在此,使用图33所表示的处理序列,对在本变形例中的接收方装置100A的处理进行说明。而且,在本变形例、图33中,用虚线包围的“通信部”表示图30的通信部105A,用虚线包围的“MAC”表示图38的MAC处理部1500,用虚线包围的“IF”表示图38的IF处理部1400,用虚线包围的“IP”表示图38的IP处理部1300。并且,在图33中,用虚线包围的“TCP”表示图38的TCP处理部1200,用虚线包围的“API”表示图38的API部1100,用虚线包围的“应用程序”表示图38的应用程序。
在本变形例中,图33所示的Seq=2的DupAck包(P15)的复制(数据流P151)具有特性,只关于这一点来进行说明。
接受了接收结束的通知的Window控制部1250,向接收缓存1240咨询缓存的可用空间,并根据咨询的结果算出Win=4。然后Window控制部1250将算出的Win通知给DupAck管理部1230。接受了Win的DupAck管理部1230由于保持着在控制流E100里的包损失信息,使用DupAck发送数“2”和规定的数值“3”,依据规定的方法算出DupAck复制数(图34所示的DupAck复制数的计算方法)。因为算出的DupAck复制数是“1”,所以DupAck管理部1230将保持的DupAck信息(Seq=2及Win=3)交付到DupAck生成部1270,并保持算出的DupAck复制数。DupAck管理部1230将DupAck信息交付到DupAck生成部之后,把从Window控制部1250接受的Win=4交付到WinUpdate生成部1260。DupAck生成部1270依据所接受的DupAck信息,生成DupAck(Num=2及Win=3)并交付到TCP发送部1220的包复制部7000。
包复制部7000将从DupAck生成部1270接受的DupAck复制向DupAck管理部1230咨询而得到的DupAck复制数的数量,并发送到TCP发送部1220。在上述的例中,因为DupAck复制数是“1”,包复制部7000不复制接受了的DupAck,而指示将那个1个DupAck发送给TCP发送 部1220。但是,在DupAck复制数是N(≥2)的情况下,包复制部7000复制DupAck,使DupAck数量的和为N个,并且对TCP发送部1220指示将所复制的DupAck(包含复制源的DupAck)全部发送。
TCP发送部1220将被指示向包复制部7000发送的DupAck交付到IP处理部1300。然后DupAck经过IF处理部1400被进行包构筑,依据MAC处理部1500的MAC发送部1520,被存入通信部105A的FIFO存储器152A中。
如此在本变形例中,通过进行以上的处理,在由TCP进行包数等管理的情况下,容易进行复制的DupAck的数量的管理。并且,在现有的通信模块中导入包复制部的情况下,就成为在TCP处理部内进行修复的情况,能够限定修复部分。
(变形例3)
在此,对关于上述实施例10中的第三变形例进行说明。
在上述实施例10中,接收方装置100A根据Window的状态的定时来复制DupAck并发送,而涉及本变形例的接收方装置100A无论Window的状态如何,都按照第一次的DupAck的发送的定时复制此DupAck并发送。
以下,关于本变形例,只对有关与上述实施例10不共通的部分进行说明。
涉及本变形例的TCP处理部1200的DupAck管理部1230具有特性。
DupAck管理部1230在接受了从TCP损失检测部1215接受的Seq的情况下,把此接受的Seq和向Window控制部1250咨询而得到的Win作为DupAck信息,由此DupAck信息算出DupAck复制数并进行保持。并且,DupAck管理部1230将DupAck信息交付到DupAck生成部1270,并将此交付了的次数作为DupAck发送数进行计数。
DupAck管理部1230针对包复制部7000的咨询,通知算出的DupAck复制数。另外,在本变形例中,关于DupAck管理部1230算出的DupAck复制数,以包为单位的管理为例来进行说明。
并且,DupAck管理部1230具有,在将DupAck复制数通知到包复 制部7000的情况下,消去从包损失通知部5000接受的包损失信息,并进一步将DupAck复制数复位到初始值的功能。作为DupAck复制数的初始值,以“1”为例来进行说明。并且,作为DupAck发送数的初始值,以“0”为例来进行说明。
图39是涉及本变形例的通信装置之间的通信序列的示意图。而且,和上述实施例10同样,此通信序列表示接收方装置100A的性能低(例如CPU的性能是133MHz)的情况的序列例。
接收方装置100A针对Seq=3的数据的接收,将Ack发送到发送方装置。此Ack(P13)的参数表示Num=2及Win=3。这是因为接收方装置100A在Seq=1的数据之后接收了Seq=3的数据,所以检测出Seq=2的数据不足的情况。请求Seq=2的Ack,在接收Seq=1时已经被发送,此Ack(P13)成为传达Seq=2的数据没有到达的情况的DupAck。此DupAck(P13)的Win与针对Seq=1的Ack(P12)的Win一样。这是由于针对Seq=1的数据的在应用程序中的接收处理尚未结束而造成的。
涉及本变形例的接收方装置100A,在发送了第一次的DupAck之时,由于检测出Seq=2的数据尚未到达,因此将复制了上次发送的DupAck(P13)的DupAck(P14)发送到发送方装置200A。
并且,接收方装置100A对Seq=4的数据的接收,和接收了Seq=3的数据的情况一样,将请求Seq=2的DupAck(P15)发送到发送方装置200A。由于发送方装置200A接收了三个DupAck(P13、P14、P15),因此高速重新发送Seq=2的重新发送数据(P25)。
图40是在接收方装置100A中的处理序列的例子的示意图。具体而言,图40表示从接收方装置100A接收Seq=1(P21)的数据,到发送第三个DupAck(P15)为止的处理序列。
以下,按照图40的处理流程,对接收方装置100A从接收Seq=3的包(P23)开始到发送Ack(P15)为止的处理序列(P231、P131、P13、P14、P241、及P141)进行说明。而且,在图40中,用虚线包围的“通信部”表示图30的通信部105A,用虚线包围的“MAC”表示图31的MAC处 理部1500,用虚线包围的“IF”表示图31的IF处理部1400。并且,在图40中,用虚线包围的“IP”表示图31的IP处理部1300,用虚线包围的“TCP”表示图31的TCP处理部1200,用虚线包围的“API”表示图31的API部1100,用虚线包围的“应用程序”表示图31的应用程序。
MAC处理部1500的MAC接收部1510将由通信部105A的接收用FIFO存储器151A读出的数据(MAC帧)(P23)进行接受。被读出的Seq=3的数据(MAC帧)通过IF处理部1400及IP处理部1300被进行非包化处理,并作为TCP包被交付到TCP接收部1210(数据流P231)。
TCP接收部1210进行Seq=3的TCP包的TCP首部的分析处理,并结束非包化处理。此时Seq=3的TCP包在TCP损失检测部1215中,由于Seq=2的数据尚未到达,所以被判断为不按顺序的数据。TCP接收部1210将Seq=3的数据交付到接收缓存1240,TCP损失检测部1215将应该按照顺序到达的序列号码(Seq=2)交付到DupAck管理部1230。接收缓存1240管理没有按照顺序到达的数据、直到按照顺序的数据到达为止所进行的保持。
DupAck管理部1230通过所接受的Seq(Seq=2)和Window控制部1250,将在接受缓存1240里的目前能够接收的Win的咨询结果的Win(Win=3)作为DupAck信息,交付到DupAck生成部1270,并将DupAck发送数计数为“1”。DupAck生成部1270依据所接受的DupAck信息,生成DupAck(Num=2及Win=3)并交付到TCP发送部1220。
并且,因为DupAck管理部1230在控制流E100中,保持着从损失通知部5000接受的包损失信息,此时,通过DupAck复制数计算方法算出DupAck的复制数。在涉及本变形例的DupAck复制数计算方法中,依据Win=3、MSS=1、及规定的数值=3,算出DupAck复制数为“2”(有关涉及本变形例的DupAck复制数计算方法的细节以后再述)。
并且,DupAck管理部1230在生成第一个DupAck之时,预先保持Seq和Win,从生成DupAck到经过由于重新发送的超时之前为止的规定的时间经过之后,将Seq和Win交付到DupAck生成部1270,也可以算 出DupAck的不足部分(复制数)的复制数。
另外,DupAck管理部1230在生成第一个DupAck之时,预先保持Seq和Win,在从生成DupAck到经过由于重新发送的超时之前为止、CPU的使用率变成规定的阈值以下之时,将Seq和Win交付到DupAck生成部1270,也可以算出DupAck的不足部分(复制数)的复制数。
其次,TCP发送部1220输出DupAck,此DupAck通过IP处理部1300及IF处理部1400,进行包构筑(数据流P131)。MAC发送部1520的包复制部7000,依据向DupAck管理部1230咨询而得到的DupAck复制数的“2”,发出将从IF处理部1400接受的MAC帧分成两个发送到MAC发送部1520的指示。MAC发送部1520复制接受的MAC帧,并且将两个MAC帧存入通信部105A的发送用FIFO存储器152A中。
被存入通信部105A的发送用FIFO存储器152A的两个DupAck(MAC帧P13、P14)通过网络3A被发送到发送方装置200A。
DupAck管理部1230在紧接发送包(P14)之后,消去从损失通知部5000接受的包损失信息。并且,将DupAck复制数初始化为“1”。
其次,MAC处理部1500的MAC接收部1510将由通信部105A的接收用FIFO存储器151A读出的包(MAC帧(P24))进行接受。被读出的Seq=4的包(MAC帧)通过IF处理部1400及IP处理部1300被进行非包化处理,并作为TCP包被交付到TCP接收部1210(数据流P241)。
TCP接收部1210进行Seq=3的TCP包的TCP首部的分析处理,并结束非包化处理。此时Seq=3的数据在TCP损失检测部1215中,由于Seq=2的数据尚未到达,所以被判断为不按顺序的数据。TCP接收部1210将Seq=3的数据交付到接收缓存1240,TCP损失检测部1215将应该按照顺序到达的序列号码(Seq=2)交付到DupAck管理部1230。接收缓存1240管理没有按照顺序到达的数据,直到按照顺序的数据到达为止所进行的保持。
DupAck管理部1230通过Window控制部1250向接收缓存1240咨询目前能够接收的Win,并将经咨询而得到的Win和通过TCP损失检测部1215接受的Seq作为DupAck信息进行保持。DupAck管理部1230将DupAck信息交付到DupAck生成部1270。DupAck生成部1270依据所接受的DupAck信息(Seq=2及Win=3),生成表示Num=2及Win=3的包(P15),并将生成的DupAck交付到TCP发送部1220。此时,DupAck管理部1230,因为未接受来自损失通知部5000的包损失信息,所以不计算DupAck复制数。DupAck复制数仍旧是“1”。
其次,TCP发送部1220输出DupAck,此DupAck通过IP处理部1300及IF处理部1400,进行包构筑(数据流P141)。进行了包构筑的DupAck(MAC帧)被MAC处理部1500的MAC发送部1520取得。此时包复制部7000向DupAck管理部1230咨询DupAck复制数,而掌握复制数是“1”的情况。依据复制数是“1”,MAC发送部1520在通信部105A的发送用FIFO存储器152A中只存入一个MAC帧。
通过MAC发送部1520而被存入通信部105A的发送用FIFO存储器152A的MAC帧,通过网络3A作为包被发送到发送方装置200A。这成为第三个DupAck,发送方装置200A启动高速重新发送。
图41是在本变形例中,表示通过TCP处理部1200的DupAck管理部1230的DupAck复制数计算方法的算法的流程图。
DupAck管理部1230在从TCP损失检测部1215接受Seq的情况下,使用向Window控制部1250咨询而得到的Win除以MSS(Max SectionSize),并检查从得出的商(Win/MSS)中减去“2”的结果是否满足规定的数值(高速重新发送所必要的DupAck的数值是“N”,例如N=3)(步骤S200)。另外,上述的MSS是发送方装置200A一次能够发送的最大的数据长度,例如在本变形例中是“1”。
并且,DupAck管理部1230检查,通过损失通知部5000接受的包损失信息是否被记录(步骤S202)。
即,步骤S200中,在DupAck管理部1230从用Win除以MSS而得出的商(Win/MSS)中减去“2”的结果为规定的数值“N”以上的情况下(步骤S200的“否”),设DupAck复制数为“1”(步骤S204)。另一方面, 在从用Win除以MSS而得出的商(Win/MSS)中减去“2”的结果不足规定的数值“N”的情况下(步骤S200的“是”),DupAck管理部1230执行步骤S202的处理。
步骤S202中,在来自损失通知部5000的包损失信息被记录的情况下(步骤S202的“是”),DupAck管理部1230依据公式“DupAck复制数=N-{(Win/MSS)-2}”算出DupAck复制数。另一方面,在包损失信息没有被记录的情况下(步骤S202的“否”),DupAck管理部1230设DupAck复制数为“1”(步骤S204)。
具体而言,在本变形例中,首先,DupAck管理部1230从Window控制部1250得到Win=3。而且,例如MSS是“1”,来自损失通知部5000的包损失信息被记录。
在此情况下,DupAck管理部1230在步骤S200中,因为((Win/MSS)-2=3/1-2=1)<(N=3),所以进行步骤S202的处理。
并且,在步骤S202中,DupAck管理部1230判断包损失信息被记录,在步骤S206中算出DupAck复制数=3-{(3/1)-2}=2。
另外,DupAck管理部1230在步骤S206中,也可以将DupAck复制数作为规定的数值“N”来计算。
如此在本变形例中,由于进行以上的处理而具有以下的效果:使发送方装置200A以最快速度启动高速重新发送,并控制由于TCP的重新发送而产生的吞吐量降低的效果;只有在接收方装置100A里的包损失的情况下,使发送方装置200A启动高速重新发送的效果;不使网络处于负荷过大状态的效果;由于复制DupAck而控制不必要的通信量的效果;控制DupAck发送所需要的接收方装置100A的CPU的消费的效果;和不发送出错的DupAck的效果。
如上所述,关于本发明使用实施例1至10及其变形例进行了说明,而且,框图(图8、图30及图35等)的各个功能块典型地是作为集成电路、即LSI被实现的。这些可以被个别地单片化,也可以被单片化成使其包含一部分或者全部的功能块(例如,也可以把存储器以外的功能块单片化。)。
在此,举例为LSI,但是,根据集成度的差异,也有被称为IC、系统LSI、超级LSI、极超级LSI的情况。
而且,集成电路化的方法不只限于LSI,也可以在专线或者通用处理器上实现。在制造LSI以后,也可以利用可编程的FPGA(FieldProgrammable Gate Array:现场可编程门阵列),或利用能够将LSI内部的电路单元的连接或设定重构的可重构处理器。
并且,如果由于半导体技术的进步或者派生其他的技术而出现替换集成电路化的技术,当然也可以使用该技术进行功能块的集成化。也可能有适用于生物技术的可能性。
而且,在各个功能块之中,也可以只将储存成为编码或者解码的对象的数据的单元不进行单片化,而是作为其他的构成。
本发明的通信装置,能够在对应本身的接收能力而自发地控制数据的发送通信量的同时,取得能够减轻该控制处理的负担的效果,例如,能够适用于同TCP以及具有与TCP同等的窗口控制功能及确认应答功能的、根据通信协议来进行接收处理的所有通信装置。

Claims (23)

1.一种通信装置,接收从其他的通信装置发送的数据,其特征在于,包括:
接收单元,接收所述数据;
第一包生成单元,生成针对在所述接收单元所接收的数据的、表示对所述其他的通信装置的应答内容的确认应答包,并且将其发送到所述其他的通信装置;以及
第二包生成单元,无论在所述接收单元的数据的接收结果如何,都生成对所述其他的通信装置请求数据发送的数据请求包,并且将其发送到所述其他的通信装置;
所述第二包生成单元为了使能够接收的数据的大小作为接收大小而被包含在所述数据请求包中,而生成该数据请求包;
所述通信装置还包括:
大小计算单元,通过在所述接收大小上加上更新量,来更新该接收大小,
所述第二包生成单元每经过一段更新时间,就使所述大小计算单元更新所述接收大小,并生成包含被更新的接收大小的所述数据请求包,且发送到所述其他的通信装置;
所述通信装置还包括:
更新决定单元,根据所述通信装置的通信能力,来决定所述更新时间及所述更新量。
2.如权利要求1所述的通信装置,其特征在于,
所述接收单元作为具有用于暂时保持被接收的数据的存储器的物理层通信设备而被构成,
所述更新决定单元根据所述存储器的容量和被保持在所述存储器中的数据的传送能力,来决定所述更新时间及所述更新量。
3.如权利要求1所述的通信装置,其特征在于,
所述更新决定单元还根据在所述通信装置中工作的应用程序所需要的比特率,来决定所述更新时间。
4.如权利要求1所述的通信装置,其特征在于,
所述第二包生成单元在每经过一段所述更新时间而生成所述数据请求包之时,在通过所述接收单元接收数据的情况下,停止生成所述数据请求包。
5.如权利要求4所述的通信装置,其特征在于,
所述第二包生成单元在每经过一段所述更新时间所进行的所述数据请求包的生成停止之时,在通过所述接收单元接收数据的情况下,重新开始每经过一段所述更新时间而进行的所述数据请求包的生成。
6.如权利要求4所述的通信装置,其特征在于,
所述第一包生成单元生成表示将能够接收的数据的大小作为应答大小的所述确认应答包,
在每经过一段所述更新时间而进行的所述数据请求包的生成停止之时,在先发送而后损失了的数据被重新发送并且由所述接收单元接收的情况下,
所述第一包生成单元生成表示比上次生成的所述确认应答包的应答大小小的应答大小的确认应答包,
所述第二包生成单元重新开始每经过一段所述更新时间而进行的所述数据请求包的生成。
7.如权利要求4所述的通信装置,其特征在于,
所述通信装置还包括延迟单元,在每经过一段所述更新时间而进行的所述数据请求包的生成停止之时,延迟通过所述第一包生成单元所进行的所述确认应答包的发送的定时。
8.如权利要求7所述的通信装置,其特征在于,
所述接收单元作为具有用于暂时保持被接收的数据的存储器的物理层通信设备而被构成,
所述通信装置还具备发送间隔决定单元,根据所述存储器的容量和被保持在所述存储器中的数据的传送能力,来决定所述确认应答包的发送间隔,
所述延迟单元为了按照由所述发送间隔决定单元决定的发送间隔来发送多个所述确认应答包,而延迟所述定时。
9.如权利要求7所述的通信装置,其特征在于,
所述通信装置还包括发送间隔决定单元,根据在所述通信装置中工作的应用程序所需要的比特率,来决定所述确认应答包的发送间隔,
所述延迟单元为了按照由所述发送间隔决定单元决定的发送间隔来发送多个所述确认应答包,而延迟所述定时。
10.如权利要求1所述的通信装置,其特征在于,
所述第二包生成单元在由所述接收单元所接收的数据的接收量超出阈值之时,开始每经过一段所述更新时间而进行的所述数据请求包的生成。
11.如权利要求1所述的通信装置,其特征在于,
所述通信装置还包括,
检测单元,对从所述其他的通信装置发送的数据的损失进行检测,
所述第一包生成单元生成表示将能够接收的数据的大小作为应答大小的所述确认应答包,在通过所述检测单元检测出损失之时,生成表示比上次生成的确认应答包的应答大小小的应答大小的确认应答包。
12.如权利要求11所述的通信装置,其特征在于,
所述第一包生成单元还在通过所述检测单元在规定时间内未检测出损失之时,生成表示比上次生成的确认应答包的应答大小大的应答大小的确认应答包。
13.如权利要求11所述的通信装置,其特征在于,
所述第一包生成单元生成,表示将上次生成的确认应答包的应答大小和损失的数据的量之间的差作为所述小的应答大小的所述确认应答包。
14.如权利要求1所述的通信装置,其特征在于,
所述第二包生成单元生成所述数据请求包,
所述数据请求包是在由所述其他的通信装置按顺序发送的数据没有按照预先规定的顺序被所述接收单元所接收的情况下,或者,在所述数据发生损失的情况下,作为应当被发送的否定应答包而被生成的。
15.如权利要求14所述的通信装置,其特征在于,
所述第二包生成单元在发生数据的损失的情况下,生成规定数的所述数据请求包并将其发送,所述数据请求包在数据的损失发生的情况下,表示与针对紧接损失发生之前通过所述接收单元所接收的数据的确认应答包相同的内容。
16.如权利要求14所述的通信装置,其特征在于,
所述通信装置包括损失检测单元,对在所述接收单元所接收的数据之中消失的损失数据进行检测,
所述第一包生成单元,
作为对从所述其他的通信装置发送的数据的确认应答,将所述确认应答包发送到所述其他的通信装置,所述确认应答包指示将通过所述损失检测单元所检测的损失数据重新发送,
所述第二包生成单元,
在通过所述第一包生成单元发送的确认应答包的发送数,不足使其对所述其他的通信装置执行所述损失数据的重新发送的必要数的情况下,无论所述其他的通信装置的数据的发送如何,从所述必要数中减去发送数得到复制数,将所述确认应答包作为所述数据请求包并按所述复制数发送到所述其他的通信装置。
17.如权利要求16所述的通信装置,其特征在于,
所述接收单元具备存储器,将从所述其他的通信装置发送的数据按顺序取得并储存在所述存储器中,
所述损失检测单元对未储存在所述存储器中就消失的损失数据进行检测。
18.如权利要求16所述的通信装置,其特征在于,
所述第二包生成单元在由所述第一包生成单元生成确认应答包之时,计算所述复制数。
19.如权利要求16所述的通信装置,其特征在于,
所述第二包生成单元,
在从所述第一包生成单元发送确认应答包以后到经过规定期间之前,从所述确认应答包被发送以后到经过规定期间之前且所述通信装置的负荷率变为规定阈值以下时,或者,在所述通信装置将所述通信装置能够接收的数据量增加的情况通知给所述其他的通信装置之前,计算所述复制数。
20.如权利要求16所述的通信装置,其特征在于,
所述第二包生成单元根据在所述通信装置能够接收的数据量计算所述复制数。
21.如权利要求20所述的通信装置,其特征在于,
所述第二包生成单元,
在由所述第一包生成单元发送最初的确认应答包之时,根据所述能够接收的数据量,计算所述第一包生成单元预定发送的发送数,通过从所述必要数中减去所述发送数,来计算所述复制数。
22.一种通信方法,是通信装置接收从其他的通信装置发送的数据的通信方法,其特征在于,包括:
接收步骤,接收所述数据;
第一包生成步骤,生成针对在所述接收步骤所接收的数据的、表示对所述其他的通信装置的应答内容的确认应答包,并且将其发送到所述其他的通信装置;以及
第二包生成步骤,生成对所述其他的通信装置请求数据的发送的数据请求包,并且将其发送到所述其他的通信装置;
在所述第二包生成步骤中,为了使能够接收的数据的大小作为接收大小而被包含在所述数据请求包中,而生成该数据请求包;
所述通信方法还包括:
大小计算步骤,通过在所述接收大小上加上更新量,来更新该接收大小,
在所述第二包生成步骤,每经过一段更新时间,就通过所述大小计算步骤更新所述接收大小,并生成包含被更新的接收大小的所述数据请求包,且发送到所述其他的通信装置;
所述通信方法还包括:
更新决定步骤,根据所述通信装置的通信能力,来决定所述更新时间及所述更新量。
23.一种集成电路,用于接收从其他的通信装置发送的数据,其特征在于,包括:
接收单元,接收所述数据;
第一包生成单元,生成针对在所述接收单元所接收的数据的、表示对所述其他的通信装置的应答内容的确认应答包,并且将其发送到所述其他的通信装置;以及
第二包生成单元,生成对所述其他的通信装置请求数据的发送的数据请求包,并且将其发送到所述其他的通信装置;
所述第二包生成单元为了使能够接收的数据的大小作为接收大小而被包含在所述数据请求包中,而生成该数据请求包;
所述集成电路还包括:
大小计算单元,通过在所述接收大小上加上更新量,来更新该接收大小,
所述第二包生成单元每经过一段更新时间,就使所述大小计算单元更新所述接收大小,并生成包含被更新的接收大小的所述数据请求包,且发送到所述其他的通信装置;
所述集成电路还包括:
更新决定单元,根据所述集成电路的通信能力,来决定所述更新时间及所述更新量。
CN2006800368286A 2005-10-03 2006-10-02 通信装置 Expired - Fee Related CN101278529B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2005290576 2005-10-03
JP290576/2005 2005-10-03
JP197892/2006 2006-07-20
JP2006197892 2006-07-20
PCT/JP2006/319661 WO2007043373A1 (ja) 2005-10-03 2006-10-02 通信装置

Publications (2)

Publication Number Publication Date
CN101278529A CN101278529A (zh) 2008-10-01
CN101278529B true CN101278529B (zh) 2011-10-19

Family

ID=37942617

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2006800368286A Expired - Fee Related CN101278529B (zh) 2005-10-03 2006-10-02 通信装置

Country Status (7)

Country Link
US (1) US20090268747A1 (zh)
EP (1) EP1933509A1 (zh)
JP (1) JP4777996B2 (zh)
KR (1) KR20080053334A (zh)
CN (1) CN101278529B (zh)
TW (1) TW200723782A (zh)
WO (1) WO2007043373A1 (zh)

Families Citing this family (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9647952B2 (en) 2004-08-06 2017-05-09 LiveQoS Inc. Network quality as a service
US9189307B2 (en) 2004-08-06 2015-11-17 LiveQoS Inc. Method of improving the performance of an access network for coupling user devices to an application server
US8009696B2 (en) 2004-08-06 2011-08-30 Ipeak Networks Incorporated System and method for achieving accelerated throughput
US7769014B2 (en) * 2007-02-13 2010-08-03 Seiko Epson Corporation Transmitting and receiving system, transmitting apparatus, and receiving apparatus
TWI355164B (en) * 2007-02-27 2011-12-21 Quanta Comp Inc Data transmitting method for wireless communicatio
JP4587053B2 (ja) 2007-08-28 2010-11-24 日本電気株式会社 通信装置、通信システム、パケット欠落検出方法、およびパケット欠落検出プログラム
JP4557028B2 (ja) * 2008-03-19 2010-10-06 ソニー株式会社 情報処理装置、情報処理方法、クライアント機器、情報処理システム
JP5247215B2 (ja) * 2008-04-04 2013-07-24 キヤノン株式会社 通信装置及びその制御方法
US9270477B2 (en) * 2008-05-28 2016-02-23 Airmagnet, Inc. Method and apparatus of measuring and reporting data gap from within an analysis tool
US8300535B2 (en) * 2009-02-24 2012-10-30 Canon Kabushiki Kaisha Information processing apparatus, method thereof, and storage medium
JP5406558B2 (ja) * 2009-02-24 2014-02-05 キヤノン株式会社 データ処理装置、データ処理方法およびプログラム
JP5460088B2 (ja) * 2009-03-17 2014-04-02 キヤノン株式会社 情報処理装置、情報処理方法およびプログラム
US8325601B2 (en) * 2009-05-08 2012-12-04 Canon Kabushiki Kaisha Reliable network streaming of a single data stream over multiple physical interfaces
JP2011081769A (ja) * 2009-09-14 2011-04-21 Ricoh Co Ltd データ転送装置、データ転送デバイスおよびデータ転送方法
JP4821904B2 (ja) * 2009-10-23 2011-11-24 エヌイーシーコンピュータテクノ株式会社 データ通信システム及びデータ通信方法
WO2011074454A1 (ja) * 2009-12-14 2011-06-23 日本電気株式会社 パケット再送制御システム、方法、及びプログラム
US8370725B2 (en) * 2010-02-01 2013-02-05 Mosys, Inc. Communication interface and protocol
US8964543B1 (en) * 2010-02-16 2015-02-24 Google Inc. System and method of reducing latency by transmitting duplicate packets over a network
JP5682618B2 (ja) * 2010-03-03 2015-03-11 日本電気株式会社 パケット再送制御システム、方法、及びプログラム
US9137278B2 (en) * 2010-04-08 2015-09-15 Vasona Networks Inc. Managing streaming bandwidth for multiple clients
JP5601029B2 (ja) * 2010-05-27 2014-10-08 ソニー株式会社 通信装置及び通信方法、並びにコンピューター・プログラム
WO2012066824A1 (ja) * 2010-11-16 2012-05-24 株式会社日立製作所 通信装置および通信システム
US8683285B2 (en) * 2010-12-29 2014-03-25 Plx Technology, Inc. Parallel packetized interconnect with simplified data link layer
US10951743B2 (en) 2011-02-04 2021-03-16 Adaptiv Networks Inc. Methods for achieving target loss ratio
JP5329581B2 (ja) 2011-02-04 2013-10-30 株式会社東芝 無線通信端末および無線通信方法
US9590913B2 (en) 2011-02-07 2017-03-07 LiveQoS Inc. System and method for reducing bandwidth usage of a network
US8717900B2 (en) 2011-02-07 2014-05-06 LivQoS Inc. Mechanisms to improve the transmission control protocol performance in wireless networks
JP5780050B2 (ja) 2011-08-17 2015-09-16 富士通株式会社 伝送システム
WO2013035897A1 (en) * 2011-09-06 2013-03-14 Alcatel Lucent A method for avoiding network congestion and an apparatus thereof
WO2013037322A1 (zh) * 2011-09-16 2013-03-21 华为技术有限公司 分片接收和发送的方法以及分片接收和发送的装置
JP5814829B2 (ja) * 2012-03-01 2015-11-17 株式会社東芝 無線通信装置及び方法
JP6146409B2 (ja) * 2012-05-30 2017-06-14 日本電気株式会社 通信装置および通信方法
US9444727B2 (en) * 2012-10-16 2016-09-13 Cisco Technology, Inc. Duplicating traffic along local detours before path remerge to increase packet delivery
US9986063B2 (en) * 2012-11-28 2018-05-29 Panasonic Intellectual Property Management Co., Ltd. Receiving terminal and receiving method
US20150012792A1 (en) * 2013-07-03 2015-01-08 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for providing a transmission control protocol minimum retransmission timer
US9584425B2 (en) * 2013-08-20 2017-02-28 Brocade Communications Systems, Inc. Bandwidth optimization using coalesced DUP ACKs
US9760577B2 (en) * 2013-09-06 2017-09-12 Red Hat, Inc. Write-behind caching in distributed file systems
CN110190937B (zh) 2013-09-29 2021-10-22 华为技术有限公司 一种数据传输的方法及设备
US9706923B2 (en) * 2014-02-25 2017-07-18 General Electric Company System and method for adaptive interference mitigation in wireless sensor network
KR102187810B1 (ko) * 2014-09-26 2020-12-08 삼성전자주식회사 통신 시스템에서 데이터 흐름 제어 장치 및 방법
JP5881071B1 (ja) * 2014-11-20 2016-03-09 パナソニックIpマネジメント株式会社 無線通信装置、無線通信システム及び無線通信方法
JP6455135B2 (ja) * 2014-12-24 2019-01-23 富士通株式会社 パケット抽出装置、パケット抽出プログラムおよびパケット抽出方法
US10768997B2 (en) 2016-12-05 2020-09-08 International Business Machines Corporation Tail latency-based job offloading in load-balanced groups
US10700978B2 (en) 2016-12-05 2020-06-30 International Business Machines Corporation Offloading at a virtual switch in a load-balanced group
US20180159922A1 (en) * 2016-12-05 2018-06-07 International Business Machines Corporation Job assignment using artificially delayed responses in load-balanced groups
CN109698762B (zh) * 2017-10-24 2020-10-23 华为技术有限公司 一种调整参数的方法及参数调整装置
CN114221905A (zh) * 2020-09-03 2022-03-22 阿里巴巴集团控股有限公司 处理单元及流控制单元、以及相关方法
US11323309B1 (en) 2021-01-14 2022-05-03 Juniper Networks, Inc. Asynchronous socket replication between nodes of a network
US11570116B1 (en) * 2021-03-10 2023-01-31 Juniper Networks, Inc. Estimating standby socket window size during asynchronous socket replication

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6178450B1 (en) * 1997-07-01 2001-01-23 Kokusai Denshin Denwa Co., Ltd. Method and apparatus for monitoring a communication link based on TCP/IP protocol by emulating behavior of the TCP protocol
CN1469601A (zh) * 2002-06-18 2004-01-21 ���µ�����ҵ��ʽ���� 使启动接收器发送速率增加最佳化
CN1511396A (zh) * 2001-04-04 2004-07-07 ����ɭ�绰�ɷ����޹�˾ 数据流控制方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2964937B2 (ja) * 1996-01-08 1999-10-18 日本電気株式会社 適応クレジット制御型転送方法
EP1128616A3 (en) * 2000-02-23 2001-09-12 Sony Corporation Communication system, communication device and communication method
EP1137217A1 (en) * 2000-03-20 2001-09-26 Telefonaktiebolaget Lm Ericsson ARQ parameter negociation in a data packet transmission system using link adaptation
US7142508B2 (en) * 2000-12-22 2006-11-28 Radiance Technologies, Inc. System and method for controlling data transfer rates on a network
US7500010B2 (en) * 2005-04-07 2009-03-03 Jeffrey Paul Harrang Adaptive file delivery system and method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6178450B1 (en) * 1997-07-01 2001-01-23 Kokusai Denshin Denwa Co., Ltd. Method and apparatus for monitoring a communication link based on TCP/IP protocol by emulating behavior of the TCP protocol
CN1511396A (zh) * 2001-04-04 2004-07-07 ����ɭ�绰�ɷ����޹�˾ 数据流控制方法
CN1469601A (zh) * 2002-06-18 2004-01-21 ���µ�����ҵ��ʽ���� 使启动接收器发送速率增加最佳化

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JP特开平9-191321A 1997.07.22

Also Published As

Publication number Publication date
CN101278529A (zh) 2008-10-01
TW200723782A (en) 2007-06-16
US20090268747A1 (en) 2009-10-29
WO2007043373A1 (ja) 2007-04-19
WO2007043373A9 (ja) 2007-06-14
JP4777996B2 (ja) 2011-09-21
KR20080053334A (ko) 2008-06-12
EP1933509A1 (en) 2008-06-18
JPWO2007043373A1 (ja) 2009-04-16

Similar Documents

Publication Publication Date Title
CN101278529B (zh) 通信装置
US7283469B2 (en) Method and system for throughput and efficiency enhancement of a packet based protocol in a wireless network
US20080291911A1 (en) Method and apparatus for setting a TCP retransmission timer
EP2887595A1 (en) Method and node for retransmitting data packets in a TCP connection
JP2004253934A (ja) 無線通信システム、サーバ、基地局、移動端末及びそれらに用いる再送タイムアウト時間決定方法
JPWO2005027456A1 (ja) 通信システム、通信装置、およびデータの再送制御方法
US20070223492A1 (en) Methods and apparatus for optimizing a TCP session for a wireless network
KR20070086410A (ko) 송신 제어 프로토콜의 왕복 시간 관리를 위한 시스템과지원 방법 및 장치
US20060209838A1 (en) Method and system for estimating average bandwidth in a communication network based on transmission control protocol
JP2006157918A (ja) 高スループットを実現する通信システム、通信端末、セッション中継装置、及び通信プロトコル
CN102664718A (zh) 无线侧tcp数据重传的方法和设备
US10187315B2 (en) Apparatus and method for optimizing communications at an intermittent communication link
Gomez et al. Tcp usage guidance in the internet of things (iot)
JP3763812B2 (ja) 通信システム及び方法
JP2013085135A (ja) ネットワーク端末装置およびデータ伝送方法
WO2021213482A1 (zh) 超时重传时间rto确定方法及相关装置
JP5178568B2 (ja) 送信装置および送信制御方法
El-Ayat et al. Array architecture for ATG with 100% fault coverage
JP2004140596A (ja) Tcp上のデータ転送における品質を推定する方法およびシステム
WO2006058257A2 (en) Method and apparatus for setting a tcp retransmission timer
JP2016019198A (ja) 通信装置、通信装置の制御方法、プログラム
JP3784801B2 (ja) 伝送制御方法、通信装置、通信システム及びプログラム
JP5375313B2 (ja) 通信装置、擬似応答装置、送信レート制御方法およびプログラム
Gomez et al. RFC 9006: TCP Usage Guidance in the Internet of Things (IoT)
JP2005150951A (ja) 受信装置、通信システム及びプログラム

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
C17 Cessation of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20111019

Termination date: 20121002