专利名称：通信终端的制作方法
技术领域：
本发明涉及通信终端，更具体的，涉及用于经诸如互联网等通信网络发送/接收音乐声音控制数据的通信终端。
背景技术：
图15是举例说明在符合MIDI(乐器数字接口)标准的电子乐器、设备等(以下称“MIDI设备”)之间的连接状态的图。各个MIDI设备经MIDI电缆连接，并且在一个MIDI设备中产生的MIDI消息(音乐声音控制数据)经MIDI电缆被发送给另一个MIDI设备。
在这种方式中，经MIDI电缆发送/接收MIDI消息是常见的。近年来，通信网络已经有了很大发展，对于通过经互联网发送/接收MIDI消息来实现二重奏演奏或合奏曲(会话)的需求正在增长。
然而，在现有的传输系统中并没有预先假定缺乏MIDI消息等情况。因此出现了这样的问题即使将现有的传输系统照原样应用到易于产生传输错误等的互联网传输中，由于MIDI消息的缺乏等等的产生，也无法完全忠实地再现演奏。
鉴于这种情况，在IETF(互联网工程任务组)中创设了用于MIDI标准的RTP有效载荷格式(例如，参见非专利文献1)。这种用于MIDI的RTP有效载荷格式被用于经诸如互联网等数据包传输网络发送MIDI消息，并且具有这样的特征，即使得能够以高效率实现具有高可靠性的数据传输。
非专利文献1
互联网URLhttp://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-format-07.txt。
然而，为了基于该用于MIDI标准的RTP有效载荷格式执行传输，在MIDI设备中不仅需要安装被用作与互联网通信相关的协议组的核心的TCP(传输控制协议)和UDP(用户数据报协议)，而且还需要安装诸如RTP(实时传输协议)、RTCP(实时控制协议)、SDP(会话描述协议)等必须耗费大量资源(CPU资源、存储器资源等)的协议。尽管如此，目前的状态是诸如电子乐器等的平台在CPU资源、存储器资源等中没有足够的空间来安装如RTP、RTCP、SDP等协议。
发明内容
由于前面所述的情况而作出了本发明，本发明的目的是提供一种通信终端，其能够经互联网有效地发送/接收MIDI消息等，而无需实施诸如RTP、RTCP、SDP等等丰富的协议。
为了实现上述目的，本发明的特征在于具有以下方案。
(1).一种通信终端，其中整合了面向连接类型的协议和无连接类型的协议，该通信终端包括输入单元，其输入音乐声音控制数据；数据包生成器，将所述输入的音乐声音控制数据分别分类到第一和第二系统，并将分类属于第一或第二系统的音乐声音控制数据整理成数据包以产生音乐声音控制数据包；以及发送器，通过使用面向连接类型的协议将属于第一系统的音乐声音控制数据包发送到目标终端，并通过使用无连接类型的协议将属于第二系统的音乐声音控制数据包发送到目标终端。
(2).根据(1)的通信终端，进一步包括第一分配单元，将表示传输顺序的序号分配给通过使用面向连接类型的协议或无连接类型的协议发送的所有音乐声音控制数据包。
(3).根据(2)的通信终端，其中，所述第一分配单元将用于标识音乐声音控制数据包的序号和已分配给在前的已通过使用面向连接类型的协议发送的音乐声音控制数据包的序号分配给通过使用无连接类型的协议发送的每个音乐声音控制数据包。
(4).根据(1)的通信终端，进一步包括第二分配单元，将表示之前已通过使用无连接类型的协议发送给目标终端的音乐声音控制数据包的历史的历史信息分配给通过使用无连接类型的协议发送的每个音乐声音控制数据包。
(5).根据(2)的通信终端，进一步包括第二分配单元，将表示之前已通过使用无连接类型的协议发送给目标终端的音乐声音控制数据包的历史的历史信息分配给通过使用无连接类型的协议发送的每个音乐声音控制数据包。
(6).根据(1)的通信终端，进一步包括空数据包生成器，产生不包含命令内容的空数据包；以及感测单元，感测通过使用无连接类型的协议发送的每个音乐声音控制数据包的产生定时，其中，当所述感测单元在预定的阈值时间之内没有感测到音乐声音控制数据包的产生定时时，所述发送器通过使用无连接类型的协议向目标终端发送由所述空数据包生成器产生的空数据包。
(7).根据(1)的通信终端，其中，所述数据包生成器将来自输入的音乐声音控制数据中的符合设置条件的音乐声音控制数据整理成数据包，以产生音乐声音控制数据包。
(8).根据(1)的通信终端，其中，所述面向连接类型的协议包括位于传输层的TCP，所述无连接类型的协议包括位于传输层的UDP，所述音乐声音控制数据包括MIDI消息，所述属于第一或第二系统的音乐声音控制数据包括系统专用消息和其他MIDI消息，并且所述发送器通过使用TCP向目标终端发送其中系统专用消息被打包为数据包的音乐声音控制数据包，通过使用UDP向目标终端发送其中其他MIDI消息被打包为数据包的音乐声音控制数据包。
(9).一种通信终端，其中整合了面向连接类型的协议和无连接类型的协议，该通信终端包括接收器，其通过使用面向连接类型的协议接收从目标终端发送的音乐声音控制数据包和通过使用无连接类型的协议接收从目标终端发送来的音乐声音控制数据包；以及恢复单元，其根据表示被分配给通过使用各协议发送的所有音乐声音控制数据包的传输顺序的序号，并根据附加到通过使用无连接类型的协议发送的音乐声音控制数据包的历史信息，恢复通过使用无连接类型的协议发送的音乐声音控制数据包。
(10).一种在使用面向连接类型的协议和无连接类型的协议的通信终端之间通信的方法，该方法包括输入音乐声音控制数据；将所述输入的音乐声音控制数据分别分类到第一和第二系统；将分类属于第一或第二系统的音乐声音控制数据整理成数据包以产生音乐声音控制数据包；通过使用面向连接类型的协议发送属于第一系统的音乐声音控制数据包；通过使用无连接类型的协议发送属于第二系统的音乐声音控制数据包。
(11).一种存储程序的计算机可读记录介质，使运行该程序的计算机执行根据(10)的方法的过程。
(12).一种在使用面向连接类型的协议和无连接类型的协议的通信终端之间通信的方法，该方法包括通过使用面向连接类型的协议接收音乐声音控制数据包和通过使用无连接类型的协议接收音乐声音控制数据包；以及恢复单元，其根据表示被分配给通过使用各协议发送的所有音乐声音控制数据包的传输顺序的序号，并根据附加到通过使用无连接类型的协议发送的音乐声音控制数据包的历史信息，恢复通过使用无连接类型的协议发送的音乐声音控制数据包。
(13).一种存储程序的计算机可读记录介质，使运行该程序的计算机执行根据(12)的方法的过程。
如上所述，根据本发明，无需使用诸如RTP、SDP等丰富的协议而经互联网来有效地发送/接收MIDI消息等是可行的。
图1是显示根据本实施例的i会话(i-Session)系统的配置的图。
图2是说明根据该实施例的传输协议的图。
图3是说明根据该实施例流经TCP流和UDP流的TCP数据包和UDP数据包的图。
图4是说明根据该实施例流经TCP流和UDP流的TCP数据包和UDP数据包的另一个图。
图5是显示根据该实施例的TCP数据包的配置的图。
图6是显示根据该实施例的UDP数据包的配置的图。
图7是说明根据该实施例在单流中的恢复方法的图。
图8是说明根据该实施例在双流中的恢复方法的图。
图9是说明根据该实施例在双流中的恢复方法的另一个图。
图10是显示根据该实施例的数据包发送处理的流程图。
图11是表示根据该实施例的多端口概念的图。
图12是表示根据该实施例的单端口概念的图。
图13是显示根据该实施例的数据包接收处理的流程图。
图14是显示根据该实施例的数据包接收处理的流程图。
图15是说明在MIDI设备之间的连接状态的图。
具体实施例方式
下面将介绍允许位于不同地方的多个用户通过经互联网发送/接收MIDI消息来实时保持会话的系统(以下称“i会话系统”)。
A.本实施例图1是显示根据本实施例的i会话系统100的配置的图。
i会话系统100由以下几部分组成经互联网350连接的多个播放器终端(player terminal)200-k(1≤k≤n)，连接至相应的播放器终端200-k的电子乐器300-k，和会话管理服务器400。在这种情况下，如果不需要详细区分，则播放器终端200-k和电子乐器300-k分别被简单地称为播放器终端200和电子乐器300。
会话管理服务器400起到中枢地(pivotally)管理由播放器终端200实施的会话等作用。电子乐器300根据由用户执行的演奏操作来产生各种MIDI消息，并将产生的MIDI消息提供给作为连接目标的播放器终端200。
播放器终端(通信终端)200通过将从电子乐器300提供的MIDI消息整理成数据包而产生MIDI数据包(音乐声音控制数据包)，然后将这些数据包发送给参与该次会话的所有播放器终端200。同时，播放器终端200接收从其他播放器终端200发送来的MIDI数据包，然后播放它们。在本实施例中，假定电子乐器300和播放器终端200分别是作为单独的主体来提供的。但是电子乐器300和播放器终端200也可以被整体地构成，例如通过将播放器终端200的功能并入电子乐器300中。
i会话系统100的第一特征图2是说明在i会话系统100中使用的传输协议的图。根据本实施例的i会话系统100通过使用TCP和UDP来发送MIDI数据包，而不需使用如RTP、SDP等丰富的协议(见图2)，TCP和UDP作为互联网350的传输协议而被广泛使用。TCP和UDP都是位于TCP/IP协议组中传输层的协议。这里，TCP是为了不失败地递送数据而具有高可靠性的协议，并且由于在其中执行顺序控制等而被称为面向连接类型的协议。相反，UDP是具有低可靠性的协议，因为对于在路中数据包的短缺等不作出响应，并由于不执行顺序控制而被称为无连接类型的协议，这与TCP不同。
在本实施例中，通过使用包含具有高可靠性的TCP和具有低可靠性的UDP的双系统传输线路来发送MIDI消息。更详细地说，播放器终端(发送器)200首先将要发送的MIDI消息分成绝对不能丢失的MIDI消息(在本实施例中，系统专用消息)和其他MIDI消息。根据这种分类，播放器终端(发送器)200通过使用具有高可靠性的TCP来发送系统专用消息，通过使用具有低可靠性的UDP来发送其他MIDI消息。
在本实施例中，示例了各种MIDI消息中仅有一种类型的MIDI消息(即系统专用消息)通过使用TCP来发送的情况。但是通过使用TCP来发送的MIDI消息的类型、数量等可以相应于i会话系统100的应用等而作出适当地变化。在下面的说明中，使用TCP的传输线路被称为TCP流，以数据包的形式流经TCP流的MIDI消息被称为TCP数据包(见图3)。类似地，使用UDP的传输线路被称为UDP流，以数据包的形式流经UDP流的MIDI消息被称为UDP数据包(见图3)。
i会话系统100的第二特征图4是示例流经TCP流和UDP流的TCP数据包和UDP数据包的图。
在本实施例中，如上所述，通过使用TCP流和UDP流(这些在下文中被统称为“双流”)以数据包的形式发送MIDI消息。因此，为了在接收器侧通过播放器终端200来正确地播放MIDI消息，必须以正确的顺序(即以传输顺序)来处理流经每个流的数据包。在本实施例中，为了实现这种处理，标识传输顺序的唯一的序号分别被分配给流经TCP流和UDP流的所有数据包，如图4所示。接收器侧的播放器终端200能够通过按序号的顺序处理各个数据包来相互同步操作。在这种情况下，因为如上所述，UDP流是具有低可靠性的传输线路，所以可能会造成UDP数据包丢失、UDP数据包的顺序颠倒(较后发送的UDP数据包比之前发送的UDP数据包更先到达接收器侧的播放器终端200，等等)及其他情形。下面描述的第三特征能够处理这些情形。
i会话系统100的第三特征图5是显示流经TCP流的TCP数据包的配置的图，图6是显示流经UDP流的UDP数据包的配置的图。
TCP数据包包含时间戳、序号和命令段。而UDP数据包包含时间戳、第一序号、第二序号、命令段和日志段(journal section)。
在TCP数据包和UDP数据包的时间戳中，分别照原样记述了i会话定时器(未示出)的定时器值。
在TCP数据包的序号中记述表示TCP数据包的传输顺序的唯一的序号。类似地，在UDP数据包的第一序号中记述表示UDP数据包的传输顺序的唯一的序号。相反，在UDP数据包的第二序号中记述已经发送了的在前的TCP数据包的序号。在这种情况下，当在前的TCP数据包不存在时(当还没有发送TCP数据包时)，在UDP数据包的第二序号中记述序号“0”。通过采用这样的配置，就能够当UDP数据包丢失时适当地执行恢复。该特征将在后面进行描述。
在TCP数据包的命令段中记述表示系统专用消息的命令内容。在UDP数据包的命令段中记述表示除系统专用消息之外的其他MIDI消息的命令内容。
在UDP数据包中提供日志段(见图6)。在日志段中记述用于在从丢失的数据包等进行恢复时所需的历史信息和表示被发送到该时间点为止的UDP数据包的历史(命令内容等)(以下称“日志”)。该日志是在上面用于MIDI的RTP有效载荷格式中引入的概念，并被用于在UDP数据包丢失时执行恢复等等。
在这种情况下，由于用于MIDI的RTP有效载荷格式和i会话系统100在数据包发送方式上是不同的，因此使用日志的恢复方法也是不同的。更详细地说，用于MIDI的RTP有效载荷格式通过仅使用UDP流(即单流)来执行数据包传输，而i会话系统100通过使用UDP流和TCP流(双流)来执行数据包传输。因此，在两个系统中恢复方法是各不相同的。然而，因为用于各恢复方法的基本概念是共同的，所以将首先说明在单流情况下的恢复方法，然后说明在双流情况下的恢复方法。
(在单流情况下的恢复方法)图7是说明在单流情况下的恢复方法的的图。表示传输顺序的序号以及表示从会话开始到该时间点所发送的UDP数据包的历史的日志被附加到流经UDP流的每个UDP数据包上。这里，例如，如图7中A所示，当所有的UDP数据包都以正常状态流经UDP流时，接收器侧的播放器终端200能够通过参考分配给每个数据包的序号来正确地处理所有的UDP数据包。
相反，如图7中B所示，当UDP数据包的一部分(序号“3”)丢失时，接收器侧的播放器终端200通过参考随后接收的UDP数据包(序号“4”)的日志来执行对丢失的UDP数据包的恢复。更具体来讲，当序号为“3”的UDP数据包在传输中丢失时，在接收器侧的播放器终端200接收了序号为“2”的UDP数据包之后，该终端接收序号为“4”的UDP数据包(见图7的B)。接收器侧的播放器终端200判定序号为“3”的UDP数据包丢失，因为所接收的UDP数据包的序号从“2”跳到“4”。基于该判定，接收器侧的播放器终端200通过参考被附加给序号为“4”的UDP数据包上的日志来执行对序号为“3”的丢失UDP数据包的恢复处理。
例如，如果命令“降低所发出的音乐声音(C4等)”被包含在序号为“3”的丢失UDP数据包中，那么序号为“3”的UDP数据包的命令内容被包含在序号为“4”的UDP数据包的日志中(见以上对日志的说明)。如果接收器侧的播放器终端200通过分析序号为“4”的UDP数据包的日志，确定命令“降低所发出音乐声音(C4等)”包含在序号为“3”的UDP数据包中，则该终端基于以上命令内容降低现在产生的音乐声音。上述恢复处理不仅可用于UDP数据包丢失的情况，还可同样地用于UDP数据包的顺序颠倒的情况。
例如，如图7中C所示，当在传输中序号为“3”的UDP数据包和序号为“2”的UDP数据包的顺序颠倒时，在接收器侧的播放器终端200接收到序号为“3”的UDP数据包的时间点，该终端判定序号为“2”的UDP数据包丢失。接收器侧的播放器终端200基于该判定执行与上述相同的恢复处理。以这种方式，通过使用序号为“3”的UDP数据包中的日志恢复了序号为“2”的UDP数据包。因此，即使之后序号为“2”的UDP数据包到达了，该序号为“2”的数据包也被舍弃(见图7中C)。
在这种情况下，如果附加到UDP数据包的中日志与附加到之前的UDP数据包中的日志相同(即，要处理的命令内容没有改变)，则即使该UDP数据包丢失，也不需要进行恢复处理，。这种情况可以通过将意思为不需要恢复处理的信息添加给UDP数据包来代替将日志附加到UDP数据包中来处理。
(在双流情况下的恢复方法)图8和图9是说明在双流中的恢复方法的图，并与上面的图7相对应。
在前的TCP数据包的序号和上述序号及日志一起被附加到流经UDP流的每个UDP数据包上(见图8和图9中括号内的数字值)。例如，如图8中A所示，在前的TCP数据包的序号“2”还被分配给序号为“3”和“4”的各UDP数据包，而在前的TCP数据包的序号“5”还被分配给分配了序号“6”的UDP数据包。在这种情况下，为了阐明在前的TCP数据包不存在的事实，序号“0”还被分配给不具有在前的TCP数据包的UDP数据包(分配了序号“1”的UDP数据包)。当在双流环境中所有的UDP数据包都以正常状态流经UDP流时，与在单流环境中的情况一样，接收器侧的播放器终端200能够通过参照被分配给每个数据包的序号来正常地处理所有的UDP数据包。
如图8中B所示，当UDP数据包的一部分丢失时，与在单流环境中的情况一样，接收器侧的播放器终端200通过参照随后接收到的UDP数据包的日志来执行对丢失UDP数据包的恢复。
更具体来讲，如图8中B所示，当序号为“4”的UDP数据包丢失时，接收器侧的播放器终端200在接收到序号为“3”的UDP数据包之后，该终端接收序号为“6”的UDP数据包。当接收器侧的播放器终端200基于接收到的UDP数据包的序号和TCP数据包的序号，判定序号为“4”的UDP数据包丢失时，该终端通过参考附加到序号为“6”的UDP数据包上的日志(该日志在本实施例中表示序号为“1”、“3”、“4”的UDP数据包的历史)来执行对序号为“4”的丢失UDP数据包的恢复。而另一方面，与单流环境中的情况不同，当数据包的顺序颠倒时执行的恢复处理将如下执行。
(模式1TCP数据包的到达提前)如图9中C所示，当由于发生数据包的顺序颠倒，数据包以如下顺序到达接收器侧的播放器终端200时TCP数据包(序号“2”)-UDP数据包(序号“1”)，较早到达的TCP数据包一到达该终端就立即被处理，而后到达的UDP数据包(序号“1”)被作为丢失的数据包来处理。通过使用随后到达的UDP数据包(序号“3”)的日志来执行对被作为丢失的数据包处理的UDP数据包的恢复。
(模式2TCP数据包的到达延迟)如图9中D所示，当由于发生数据包的顺序颠倒，数据包以如下顺序到达接收器侧的播放器终端200时UDP数据包(序号“3”)-TCP数据包(序号“2”)，较早到达的UDP数据包被暂时保存在缓冲器等之中，并且直到被延迟的TCP数据包到达该终端才开始处理。如上所述，为了判定TCP数据包的到达是否延迟，将本应该比相关数据包更早被处理的在前的TCP数据包的序号添加到每个UDP数据包。接收器侧的播放器终端200通过参考被添加到相关UDP数据包的在前TCP数据包的序号，判定相关UDP数据包的处理是否应该被延迟。当在前的TCP数据包没有到达时，相关UDP数据包的处理被延迟，直到延迟的TCP数据包到达该终端。通过以上处理，实现了双流环境中的恢复方法。
i会话系统100的第四特征在被用于感测发送器侧的播放器终端200和接收器侧的播放器终端200之间的通信是否断开的配置方面，i会话系统100也具有特征。
更详细来讲，在通信期间，发送器侧的播放器终端200每一秒向接收器侧的播放器终端200发送至少一个数据包。发送器侧的播放器终端200总是感测数据包产生定时。当发送器侧生成器的播放器终端(空数据包生成器)200感测到在预定的阈值时间内(例如，在1秒内)没有数据包被产生/发送时，该终端产生其命令段为空的数据包(换言之，不包含命令内容的空数据包)，然后将该数据包发送到接收器侧的播放器终端200。在这种情况下，该包的日志段不是空的，而且在日志段中记述直到该时间点为止已被发送的UDP数据包的日志。
而另一方面，当接收器侧的播放器终端200在预定的时间(例如3秒)之内没有接收到UDP数据包时，该终端认为与发送器侧的播放器终端200的通信断开。
当采用前面的配置时，即使没有从发送器侧的终端发送活动感测消息(被发送的用于防止当MIDI电缆断开时在接收器侧的终端声音一直鸣响的信息)，接收器侧的终端也能够判定上述通信是否断开，，这与现有技术不同。以这种方式，通过去除发送器侧的终端中的活动感测消息，TCP/IP通信中的带宽能够被有效地使用。这里，在上面的例子中定义的时间等(例如，最小时间间隔，在该间隔内从发送器侧的播放器终端200发送UDP数据包，等等)可以相应于i会话系统100的设计等而作适当地改变。
将参考图10至图14和下面的其他内容来说明实现该i会话系统100的每个播放器终端200的操作。
数据包发送操作图10是显示由每个播放器终端200的MIDI发送部分执行的数据包发送处理的流程图。MIDI发送部分提供如下功能将从连接的电子乐器等提供的MIDI消息整理成数据包，然后将该消息发送到参与该会话的所有播放器终端200。通过协同操作被整合到各播放器终端200中的硬件资源(通信设备、CPU、存储器，等等)和被存储在存储器中的软件来实现该MIDI发送部分。
当经MIDI驱动器(未示出)从电子乐器接收到MIDI消息时，MIDI发送部分(输入单元)从接收的MIDI消息中除去未进入TCP流和UDP流的MIDI消息(即，未进入双流的MIDI消息)(步骤S1-＞步骤S2)。在这种情况下，例如，定时时钟、活动感测消息、关闭所有音符(all-note-off)消息、利用运行状态的消息等可能被列为除去的MIDI消息。可以相应于i会话系统100的应用等，适当地设置/改变哪些MIDI消息应该被除去以及哪些MIDI消息应该被整理成数据包(即设置条件)。
在MIDI发送部分通过如上所述除去没有进入双流的MIDI消息而仅提取出进入双流的MIDI消息(即符合设置条件的MIDI消息)之后，该部分根据由指令设备(未示出)给出的端口分配命令将MIDI消息分发给多个端口(步骤S3)。现在，在本实施例中，假定的是其中定义了多个可用端口的多端口(见图11)。但是其中使用一个端口的单端口(见图12)也同样可以采用。
在MIDI发送部分执行了这样的分发之后，该部分通过参考i会话定时器将临时时间戳附加到分配给每个端口的每个MIDI消息上，然后在由每个端口提供的每个MIDI消息缓冲器(未示出)中顺序存储这些消息(步骤S4-＞步骤S5)。然后，MIDI发送部分从MIDI消息缓冲器中收集得到一个数据包的MIDI消息(步骤S6)。在这种情况下，由于来自MIDI消息的系统专用消息不能与其他MIDI消息一起同时发送，MIDI发送部分分别收集得到系统专用消息和其他MIDI消息。这里，响应i会话系统100的应用等来适当地设置被打包到一个数据包中的MIDI消息的数据量。
然后，当获得的MIDI消息是除系统专用消息之外的MIDI消息(以下称“其他MIDI消息”)时，MIDI发送部分(数据包生成器)判定该消息应该被放到UDP流上来发送，然后通过将获得的其他MIDI消息整理成数据包来产生UDP数据包(步骤S7-＞步骤S8)。MIDI发送部分(第一分配单元和第二分配单元)将表示UDP数据包的传输顺序的序号和被分配给在前的TCP数据包的序号分配给以这种方式产生的UDP数据包，然后添加表示直到现在所发送的UDP数据包的历史的日志(步骤S9-＞步骤S10)。然后，MIDI发送部分(发送器)将添加了序号和日志的数据包发送到参与该会话的所有播放器终端200(步骤S11)。然后，处理结束。
而另一方面，当获得的MIDI消息是系统专用消息时，MIDI发送部分(数据包生成器)判定该消息应该被放到TCP流上来发送，然后划分该消息以将获得的系统专用消息包含在一个数据包中，然后产生TCP数据包(步骤S7-＞步骤S12-＞步骤S13)。在MIDI发送部分(发送器)以这种方式产生包含系统专用消息的TCP数据包之后，该部分分配表示TCP数据包的传输顺序的序号(步骤S14)，然后将该数据包发送到参与该会话的所有播放器终端200(步骤S11)。然后，处理结束。
数据包接收操作图13和图14是显示由每个播放器终端200的MIDI接收部分执行的数据包接收处理的流程图。这里，MIDI接收部分提供以下功能将从其他播放器终端200发送的数据包复原为MIDI消息并在适当的定时合并由复原的MIDI消息指示的命令。如同MIDI发送部分，通过协同操作被整合到各播放器终端200中的硬件资源(通信设备、CPU、存储器，等等)和被存储在存储器中的软件来实现MIDI接收部分。
当MIDI接收部分(接收器)经互联网350等从其他播放器终端200接收数据包时，该部分判定所接收的数据包是UDP数据包还是TCP数据包(步骤Sa1-＞步骤Sa2)。当MIDI接收部分确定所接收的数据包是UDP数据包时，该部分将UDP数据包暂且存储在缓冲器中(步骤Sa2-＞步骤Sa3)。暂且将所接收的数据包存储在缓冲器中的原因是在本应该较早到达的TCP数据包没有到达等情况下，UDP数据包的处理必须被延迟，直到TCP数据包到达。
MIDI接收部分(恢复单元)检查分配给UDP数据包的序号、分配给直到现在所接收到的TCP数据包的序号，等等，然后分析添加到UDP数据包的日志等(步骤Sa4)。如果MIDI接收部分(恢复单元)根据分析结果判定恢复处理是需要的(步骤Sa5是)，该部分通过使用日志等来执行恢复处理以重新产生丢失的UDP数据包(步骤Sa6)。在这种情况下，由于上面描述了恢复处理的细节，因此省略了对该处理的说明。
在MIDI接收部分执行了恢复处理之后，该部分将指示应当执行时间的时间戳附加到MIDI消息上，然后存储在MIDI命令队列中(步骤Sa7-＞步骤Sa8)。
而另一方面，如果MIDI接收部分判断从其他播放器终端200接收的数据包是TCP数据包时，则MIDI接收部分判断该TCP数据包中包含的系统专用消息是否已被划分(步骤Sa2-＞步骤Sa12)。如果MIDI接收部分判断该消息已被划分，则通过使用被划分的每个系统专用消息，恢复事先划分的系统专用消息(步骤Sa13)。然后，MIDI接收部分将待执行时间的时间戳添加到恢复后的系统专用消息中，并将其存储到专门的系统专用消息缓冲器(未示出)(步骤Sa14-＞步骤Sa15)。
如果在MIDI命令队列或者系统专用消息缓冲器中存储所接收的MIDI消息，则MIDI接收部分从存储在所述MIDI命令队列或者系统专用消息缓冲器中的全部MIDI消息中选择应该被最先处理的MIDI消息，并将其抽取出。然后，MIDI接收部分将被附加给所取出的MIDI消息的时间戳与i会话计时器(未示出)所示出的时间进行比较，以判断是否到达该事件的处理定时(步骤Sa10)。当进行在步骤Sa10期间重复执行到达处理定的确定时，MIDI接收部分执行适当的MIDI消息处理(步骤Sa11)，并且通过将该事件所示出的MIDI命令传送到MIDI驱动器来结束处理。所述的MIDI命令被从MIDI驱动器送往音响(未示出)，从而基于该MIDI命令来产生音乐。
如上所述，根据本实施例，参与会话的每个播放器终端能够使用现有的TCP和UDP来有效地发送/接收MIDI数据包，而无需实施诸如RTP、RTCP和SDP等丰富的协议。
通过以上述方式设置被TCP数据包和UDP数据包中所采用的序号和日志，能够通过支持双流的简单方法来恢复丢失的数据包。
由于根据本实施例的播放器终端200的功能可以通过计算机程序来执行，该程序能够经由存储该程序的计算机可读记录介质(CD-ROM等)和通信网络(互联网等)来散布。当然，能够用其中安装有执行上述功能的CPU、ROM等的专用设备来构成播放器终端200。
权利要求
1.一种整合了面向连接类型的协议和无连接类型的协议的通信终端，该通信终端包括输入单元，其输入音乐声音控制数据；数据包生成器，将所述输入的音乐声音控制数据分别分类到第一和第二系统，并将分类属于第一或第二系统的音乐声音控制数据整理成数据包以产生音乐声音控制数据包；以及发送器，通过使用面向连接类型的协议将属于第一系统的音乐声音控制数据包发送到目标终端，并通过使用无连接类型的协议将属于第二系统的音乐声音控制数据包发送到目标终端。
2.根据权利要求1的通信终端，进一步包括第一分配单元，其将表示传输顺序的序号分配给通过使用面向连接类型的协议或无连接类型的协议发送的所有音乐声音控制数据包。
3.根据权利要求2的通信终端，其中，所述第一分配单元将用于标识音乐声音控制数据包的序号和已分配给在前的音乐声音控制数据包的序号分配给通过使用无连接类型的协议发送的每个音乐声音控制数据包，其中所述在前的音乐声音控制数据包已通过使用面向连接类型的协议发送。
4.根据权利要求1的通信终端，进一步包括第二分配单元，将历史信息分配给通过使用无连接类型的协议发送的每个音乐声音控制数据包，该历史信息表示之前通过使用无连接类型的协议发送到目标终端的音乐声音控制数据包的历史。
5.根据权利要求2的通信终端，进一步包括第二分配单元，将历史信息分配给通过使用无连接类型的协议发送的每个音乐声音控制数据包，所述历史信息表示之前通过使用无连接类型的协议发送到目标终端的音乐声音控制数据包的历史。
6.根据权利要求1的通信终端，进一步包括空数据包生成器，产生不包含命令内容的空数据包；以及感测单元，感测通过使用无连接类型的协议发送的每个音乐声音控制数据包的产生定时，其中，当所述感测单元在预定的阈值时间之内没有感测到音乐声音控制数据包的产生定时时，所述发送器通过使用无连接类型的协议向目标终端发送由所述空数据包生成器产生的空数据包。
7.根据权利要求1的通信终端，其中，所述数据包生成器将来自输入的音乐声音控制数据中的符合设置条件的音乐声音控制数据整理成数据包，以产生音乐声音控制数据包。
8.根据权利要求1的通信终端，其中，所述面向连接类型的协议包括位于传输层的TCP，所述无连接类型的协议包括位于传输层的UDP，所述音乐声音控制数据包括MIDI消息，所述属于第一或第二系统的音乐声音控制数据包括系统专用消息和其他MIDI消息，并且所述发送器通过使用TCP向目标终端发送其中系统专用消息被打包为数据包的音乐声音控制数据包，通过使用UDP向目标终端发送其中其他MIDI消息被打包为数据包的音乐声音控制数据包。
9.一种整合了面向连接类型的协议和无连接类型的协议通信终端，该通信终端包括接收器，其通过使用面向连接类型的协议接收从目标终端发送的音乐声音控制数据包和通过使用无连接类型的协议接收从目标终端发送的音乐声音控制数据包；以及恢复单元，其根据表示被分配给通过使用各协议发送的所有音乐声音控制数据包的传输顺序的序号，并根据被附加到通过使用无连接类型的协议发送的音乐声音控制数据包中的历史信息，恢复通过使用无连接类型的协议发送的音乐声音控制数据包。
10.一种在使用面向连接类型的协议和无连接类型的协议的通信终端之间通信的方法，该方法包括输入音乐声音控制数据；将所述输入的音乐声音控制数据分别分类到第一和第二系统；将分类属于第一或第二系统的音乐声音控制数据整理成数据包以产生音乐声音控制数据包；通过使用面向连接类型的协议发送属于第一系统的音乐声音控制数据包；和通过使用无连接类型的协议发送属于第二系统的音乐声音控制数据包。
11.一种存储程序的计算机可读记录介质，所述程序使运行该程序的计算机执行根据权利要求10的方法的过程。
12.一种在使用面向连接类型的协议和无连接类型的协议的通信终端之间通信的方法，该方法包括通过使用面向连接类型的协议接收音乐声音控制数据包，并通过使用无连接类型的协议接收音乐声音控制数据包；以及恢复单元，其根据表示被分配给通过使用各协议发送的所有音乐声音控制数据包的传输顺序的序号，并根据被附加到通过使用无连接类型的协议发送的音乐声音控制数据包中的历史信息，恢复通过使用无连接类型的协议发送的音乐声音控制数据包。
13.一种存储程序的计算机可读记录介质，所述程序使运行该程序的计算机执行根据权利要求12的方法的过程。
全文摘要
采用被广泛用作传输协议的TCP和UDP来作为用于发送MIDI消息的协议。发送器侧的播放器终端将发送的MIDI消息分类为绝对不应丢失的系统专用消息和其他MIDI消息。发送器侧的播放器终端通过使用具有高可靠性的TCP来发送系统专用消息，通过使用具有低可靠性的UDP来发送其他MIDI消息。
文档编号G06F13/00GK1661989SQ20051000910
公开日2005年8月31日 申请日期2005年2月4日 优先权日2004年2月4日
发明者多田幸生 申请人:雅马哈株式会社