基于解析器的ndn中支持有状态任播的方法和系统的制作方法
【技术领域】
[0001]本发明涉及命名数据网络(Named Data Networking, NDN)技术领域，尤其涉及一种基于解析器的NDN中支持有状态任播的方法和系统。
【背景技术】
[0002]目前，用户对互联网的访问已经从点对点通信为主转为内容获取为主。而传统的TCP/IP网络仅传输内容，并不感知内容，从而造成了网络上大量的冗余流量传输。为了解决由于内容获取而引发的内容爆炸，研究界提出了以内容为中心的网络NDN，实现了内容和地址以及发送者和接收者的解耦，并提供泛在的内置缓存来满足用户对内容的具有重尾特征的异步访问。
[0003]现有互联网存在许多大规模的具有亿万的服务，如Google，Facebook,微信等。这些服务通常都有一组物理上分布但提供相同服务的服务器或服务器集群。对用户而言，这类服务本质上属于任播服务。但是，现有NDN的传输模式将发送者和接收者解耦，难以保证同一会话中的请求路由到同一个服务节点，导致无法直接实现有状态任播服务。因此，有必要提出一种NDN中能支持有状态任播的技术。
【发明内容】
[0004]本发明为解决上述技术问题，提供一种支持NDN中有状态任播的方法和系统，能不破坏CCN内容路由器转发引擎的转发逻辑。所述技术方案如下:
[0005]第一方面，本发明提出一种NDN中支持有状态任播的服务请求端方法，包括下述步骤:
[0006]向解析器发送对某个通用服务名的解析请求；
[0007]接收解析器返回的解析应答，从解析应答中获取与通用服务名对应的服务器或服务器绑定服务名的列表；
[0008]从服务器或服务器绑定的服务名列表中选择一个服务器或服务器绑定的服务名；
[0009]通过与服务器绑定的服务名发送服务请求；
[0010]接收服务器发送的响应数据。
[0011]其中，通用服务名对应于一组服务器或服务器绑定的服务名，由服务器和通用服务名可以构造出服务器绑定的服务名，每个服务器绑定的服务名都提供相同的服务。
[0012]其中，所述解析请求，除了包括通用服务名，还可以选择性地包括请求端相关的信息。
[0013]其中，依赖于解析服务的策略，不同的请求端或同一请求端不同次解析请求获得的服务器或服务器绑定服务名的列表可能不一样。
[0014]其中，当解析完成后，请求服务端通过与服务器绑定的服务名发送服务请求，该服务请求的请求名字还可以选择性地包括与请求端相关的信息。
[0015]其中，服务请求端从服务器接收的响应数据，其中可以选择性包含服务器端为会话生成的唯一会话标识，服务请求端在后续请求中应包含该会话标识以方便服务器端将服务请求映射到已建立会话。
[0016]第二方面，本发明提出一种NDN中支持有状态任播的系统，主要包括:
[0017]客户端:用于构造解析请求，接收解析应答，选择提供服务的服务器；还用于构造服务请求，接收服务响应。
[0018]服务端:用于接收服务请求，维持服务的会话状态，生成响应消息；还用于将服务器标识前缀向路由系统进行通告；
[0019]中间路由器:用于服务器标识前缀的路由通告和转发，建立转发表，转发请求消息，返回响应消息；
[0020]解析服务器:用于接收解析请求、返回解析应答；
[0021]注册服务器:用于接收通用服务名和服务器或服务器绑定服务名对应关系的注册请求，并存储该对应关系。
[0022]本发明采用以上技术方案与现有技术相比，具有以下技术效果:
[0023]通过本发明，能在NDN中支持有状态的任播，并且对具体的应用服务透明。另外，本发明所提出的技术没有破坏CCN内容路由器转发引擎的转发逻辑。
[0024]本发明附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本发明的实践了解到。
【附图说明】
[0025]图1示出了依据本发明一实施方式的NDN中支持有状态任播的服务请求端方法流程图。
[0026]图2示出了依据本发明一实施方式的NDN中支持有状态任播的时序图。
[0027]图3示出了依据本发明一实施方式的NDN中支持有状态任播的时序图。
[0028]图4示出了依据本发明一实施方式的NDN中支持有状态任播的时序图。
[0029]图5示出了依据本发明一实施方式的NDN中支持有状态任播的时序图。
[0030]图6示出了依据本发明一实施方式的NDN中支持有状态任播的系统示意图。
【具体实施方式】
[0031]下面详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。
[0032]本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。
[0033]本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。
[0034]图1示出了依据本发明一实施方式的NDN中支持有状态任播的服务请求端方法流程图，包括:
[0035]101，向解析器发送对某个通用服务名的解析请求；
[0036]102，接收解析器返回的解析应答，从解析应答中获取与通用服务名对应的服务器或服务器绑定服务名的列表；
[0037]103，从服务器或服务器绑定服务名列表中选择一个服务器或服务器绑定服务名；
[0038]104，通过与服务器绑定的服务名发送服务请求；
[0039]105，接收服务器发送的响应数据。
[0040]其中，通用服务名对应于与一组服务器或服务器绑定的服务名，通过服务器和通用服务名可以构造出服务器绑定的服务名，每个服务器绑定的服务名都提供相同的服务。
[0041]所述解析请求，除了包括通用服务名，还可以选择性地包括请求端相关的信息。在解析请求中包括请求端相关信息的好处是可以在不改变NDN转发逻辑的前提下保证不同请求者发出的对相同内容的解析请求不会被中间路由节点抑制，也不会被缓存所服务。另一方面，在解析请求名字中包括请求端相关信息可以让解析服务器获取请求端的个性化信息，从而提供个性化的智能解析服务，例如选择距离请求者更近的服务器返回给请求者。
[0042]为了能将解析请求路由到解析服务器，需要将解析服务器的标识前缀在路由系统中进行通告，并在转发表中建立相应的表项。
[0043]依赖于解析服务的策略，不同的请求端或同一请求端不同次解析请求获得的服务器或服务器绑定服务名的列表可能不一样。例如，服务器端可以采用Round-Robin策略，以实现不同服务器的负载均衡，服务器端还可以采用其它的策略，本发明对服务器端采用的策略不加限制。
[0044]当解析完成后，请求服务端选择一个服务器，通过与服务器绑定的服务名发送服务请求。请求服务端可以简单地根据解析服务器返回的服务器列表逐个尝试，直到一个成功响应为止。请求服务端也可以采用其它的服务器选择策略，本发明对请求选在返回的服务器列表中选择服务器的策略不加限制。
[0045]为了能将包含服务器绑定服务名的请求转发到正确的服务器，需要将服务器标识前缀在路由系统中进行通告，并在转发表中建立相应的表项。
[0046]当服务请求端发送服务请求时，该服务请求的请求名字除了包括服务器绑定的服务名之外，还可以选择性地包括与请求端相关的信息。在请求中包括请求端相关信息的好处是可以在不改变NDN转发逻辑的前提下保证不同请求者发出的对相同内容的请求不会被中间路由节点抑制，也不会被缓存所服务。另一方面，在请求名字中包括请求端相关信息可以让服务器获取请求端的个性化信息，从而提供个性化的服务。
[0047]服务请求端发出服务请求后，等待从服务器接收的响应数据。服务器在第一次接收到一个服务会话的请求后，可以选择性为会话生成的唯一会话标识，并包含在第一个响应数据中。服务请求端接收到第一个响应数据后，可以提取出该唯一会话标识，并在后续请求中包含该会话标识，以方便服务器端将服务请求映射到已建立会话。
[0048]图2示出了依据本发明一实施方式的NDN中支持有状态任播的时序图。服务请求端Requestor首先以解析服务器标识和通用服务名作为解析请求报文的名字前缀，并可选地在后面附加请求端相关的信息，所发送的解析请求的请求名为:/resolver/servicename/[client-specific-1nfo]。中间路由器将根据解析服务器标识前缀/resolver将解析请求路由到解析服务器。解