CN110178351A - 多客户端/多服务器管理方法和系统 - Google Patents
多客户端/多服务器管理方法和系统 Download PDFInfo
- Publication number
- CN110178351A CN110178351A CN201680091995.4A CN201680091995A CN110178351A CN 110178351 A CN110178351 A CN 110178351A CN 201680091995 A CN201680091995 A CN 201680091995A CN 110178351 A CN110178351 A CN 110178351A
- Authority
- CN
- China
- Prior art keywords
- client
- server
- factor
- request
- fom
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/101—Server selection for load balancing based on network conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1019—Random or heuristic server selection
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computer And Data Communications (AREA)
Abstract
公开了一种用于管理多客户端/多服务器系统(1)的方法。根据一些实施例,所述方法包括以下步骤:当所述服务器(3)中的至少一个服务器从客户端(5)之一接收到连接请求时,服务器(3)计算发出请求的客户端的品质因数(FoM);服务器(3)以一概率向发出请求的客户端(5)发送连接接受响应,该概率取决于品质因数;接收连接接受响应的发出请求的客户端(5)加入服务器(3)并开始与之通信。
Description
技术领域
本发明涉及多客户端/多服务器系统以及用于管理所述系统的方法。
背景技术
一般而言,多客户端/多服务器系统是由作为客户端操作的若干电子设备组成的集合,其与作为服务器操作的多个电子设备进行数据通信。每个客户端与至少一个服务器处于数据通信关系。每个服务器又与至少一个客户端处于数据通信关系,并且通常与多个客户端处于数据通信关系。服务器可以连接到网关,以便与远程监视中心站进行通信。服务器通过快速可靠的通信信道(例如,TCP/IP网络)连接到网关,其允许管理高数据带宽以将信息转发到网关。提供无线或有线网络以连接客户端和服务器。
可以例如在可再生能源装置领域中找到这种多客户端/多服务器系统的示例,诸如风力涡轮机装置、光伏板领域、燃料电池等。使用低功率设备(例如微型逆变器)涉及使用分布在现场的大量这样的逆变器(例如,多达数百个逆变器)。每个逆变器表示多客户端/多服务器系统的客户端。每个客户端连接到服务器并且,由于大量客户端,需要多个服务器。
例如,必须小心管理将客户端连接到服务器的信道,以防止通信数据过载或与可用带宽相关的问题。
在现场的电子设备(例如连接到光伏板、风力涡轮机、燃料电池或其它可再生能源的逆变器)的物理定位并不总是可预测的。有时,光伏板以及与其连接到的电子设备安装在不对称的屋顶上。在其它情况下,它们遍布广泛的现场。
多客户端/多服务器系统的一个关键方面涉及在数据流量带宽方面平衡客户端与服务器之间的通信负载。
在一些情况下,当客户端由可再生能源供电时,客户端通过相应的服务器连接到网络,并在没有能源可用时离开网络。例如,在太阳能设备中,逆变器将在日出时连接到网络,并将在日落时离开网络。类似地,耦合到风力涡轮机的逆变器将仅在风可用时才连接到网络。当客户端需要再次连接到网络时,例如在日出时,或当风再次开始吹风时,必须正确地重新建立每个客户端与相应服务器之间的通信。
尤其是当使用无线网络将客户端连接到服务器时,环境因子会对客户端-服务器通信产生不利影响。在一些情况下,客户端-服务器连接会丢失。在这种情况下,可能需要进行客户端-服务器重新指派。
已经开发了各种标准在多客户端/多服务器环境中将客户端指派给服务器,以实现适当的负载平衡。事实证明这些标准并不令人满意。
因此,需要一种更高效的标准来管理多客户端/多服务器系统中的负载平衡。
发明内容
根据本发明,描述了一种用于管理多客户端/多服务器系统的方法。所述系统包括多个服务器和多个客户端,每个客户端需要到所述服务器中的至少一个服务器的连接。根据本文描述的实施例,所述方法包括以下步骤:
-当所述服务器中的至少一个服务器从客户端之一接收到连接请求时,服务器计算发出请求的客户端的品质因数;其中,品质因数确定发出请求的客户端被加入到服务器的概率。
本文在以下将描述使用品质因数的不同方式。在某些情况下,需要了解由多个服务器计算的品质因数,例如,以确定哪个服务器已计算了最高品质因数。在其他实施例中,这可能不是必需的。因此,品质因数可以与随机数进行比较,例如,该随机数的范围在0到99之间,并且可以与可以归一化到100的品质因数进行比较,即,品质因数的范围也可以在0到99之间。
根据本发明的一些实施例,所述方法包括以下步骤:
当所述服务器中的至少一个从客户端之一接收到连接请求时,服务器为发出请求的客户端计算品质因数;
服务器以一概率向发出请求的客户端发送连接接受响应,该概率取决于品质因数;
接收连接接受响应的发出请求的客户端加入服务器并开始与之通信。
根据本发明的其他实施例,所述方法包括以下步骤:
-当服务器从客户端之一接收到连接请求时,服务器为发出请求的客户端计算相应的品质因数;
-比较所述服务器计算出的品质因数,并且发出请求的客户端将加入到计算出最高品质因数的服务器。
如果多个服务器彼此处于数据通信关系,并且部分或全部所述服务器计算同一发出请求的客户端的品质因数,则客户端可以连接到已计算出最高品质因数的服务器。例如,已计算出最高品质因数的服务器将发出连接接受响应,而其他服务器将不发出响应或将发出不接受响应。在这种情况下,最高品质因数提供了100%的发送连接接受响应的概率,而所有剩余(较低)品质因数对应于0%的生成连接接受响应的概率。
在一些实施例中,可以预见为品质因数设置最小阈值,以使得如果没有服务器计算达到最小阈值的品质因数,则将不会生成连接接受响应。然后发出请求的客户端将发出重新连接请求。可使用最小阈值,例如以防止异常和临时干扰因子导致不适当的连接被建立。
如果服务器彼此不通信,则无法将接收到连接请求的各个服务器计算出的品质因数彼此进行比较。在这种情况下,可以触发客户端加入例程。该例程使每个已计算了品质因数的服务器以一概率生成连接接受响应,该概率仅取决于由服务器本身计算的品质因数的值。例如,品质因数可以被归一化到100,并且可以与包括在0到99之间的随机数进行比较。如果品质因数大于与其比较的随机数时,则将生成连接接受响应。
在一些实施例中,如果多于一个服务器生成连接接受响应,那么发出请求的客户端将例如加入服务器,其连接接受响应首先被接收。可替换地,连接接受响应可以包含品质因数。
在一些实施例中,客户端可以被配置为在响应服务器中选择计算出最高品质因数的服务器。
在又一实施例中,可以提供用于比较多个服务器计算的品质因数的措施。如果提供了此功能,则可以将多个服务器计算出的品质因数彼此进行比较,并可以找到最高品质因数。只有计算出最高品质因数的服务器才会向发出请求的客户端发出连接接受响应。
可以作为以下至少一个的函数来计算品质因数:依赖于客户端的因子;依赖于服务器的因子;依赖于传输信道的因子;并且优选地,所述因子中的至少两个。在一些实施例中,品质因数被计算为至少一个依赖于客户端的因子和至少一个依赖于服务器的因子的组合函数。在还有一些实施例中,品质因数被计算为至少一个依赖于客户端的因子、至少一个依赖于服务器的因子和至少一个依赖于传输信道的因子的组合函数。
在一些实施例中,系统的服务器可以周期性地拒绝至少一个与其连接的客户端,从而使被拒绝的客户端处于非连接状态。处于非连接状态的客户端将生成连接请求。从被拒绝的客户端接收所述连接请求的服务器将计算品质因数,以使得被拒绝的客户端将再次连接到系统的服务器。服务器可以计算拒绝品质因数以确定与之相连的给定客户端被拒绝的概率。
在所附权利要求中阐述了根据本发明的方法的其它特征和实施例,并且在以下描述中公开了这些特征和实施例。
附图说明
当结合附图考虑时,通过参考以下详细描述,可以更容易地获得对本发明所公开的实施例及其许多附带优点的更完整的理解,其中:
图1图示了多客户端/多服务器系统的示意图,其中可以实现本文公开的方法;
图2示意性地图示了被配置为多客户端/多服务器系统的光伏面板装置的一部分;
图3图示了每个客户端可以采取的状态和动作的示图;
图4图示了在其中一个服务器停止服务的情况下的图1的示意图。
具体实施方式
以下对示例性实施例的详细描述参考附图。不同附图中的相同标号识别相同或相似的元件。此外,附图不一定按比例绘制。而且,以下详细描述不限制本发明。相反,本发明的范围由所附权利要求限定。
整个说明书中对“一个实施例”或“实施例”或“一些实施例”的引用意味着结合实施例描述的特定特征、结构或特点包括在所公开的主题的至少一个实施例中。因此,在整个说明书中各处出现的短语“在一个实施例中”或“在实施例中”或“在一些实施例中”不一定是指相同的(一个或多个)实施例。另外,特定特征、结构或特点可以在一个或多个实施例中以任何合适的方式组合。
在以下描述中,将具体参考太阳能设备,其包括光伏面板和相关逆变器的布置,后者代表多客户端/多服务器装置的客户端。但是,应该理解的是,本文公开的本发明的各种特征可以在其它类型的装置和不同环境中实现,其中客户端和服务器表示数据通信关系中的通用电子设备。
在图1中,示意性地表示了通用的多客户端/多服务器网络或系统1。系统1可以包括多个服务器3.1、3.2、3.3、3.4。每个服务器3.j是主设备,多个从设备或客户端5.1-5.n可以连接到其,以便与其建立数据通信关系。通常每个客户端只与一个服务器处于数据通信关系。在图1的示意图中,客户端的第一组6.1与服务器3.1进行数据通信,客户端的第二组6.2与服务器3.2进行数据通信,客户端的第三组6.3与服务器3.3进行数据通信,并且客户端的第四组6.4与服务器3.4进行数据通信。在下文中,通用服务器将简单地用标号3指定,通用客户端将用标号5指定,并且通用客户端组将用标号6指定。
虽然在图1的示意图中客户端5的每个组6包括相同数量的客户端5,但是从以下描述中将清楚的是,指派给每个服务器3的客户端5的数量可以是不同的。而且,在图1的示意图中,六个客户端5被指派给每个服务器3。但是,应该理解的是,这仅仅是表示,并且在实际装置中,通常更大数量的客户端5可以与每个服务器6处于数据通信关系。例如,每个服务器3可以包括多达30个或更多个通信时隙,以与对应数量的客户端5连接。
标号9和10分别示意性地表示客户端5和服务器3之间以及服务器3和网关11之间的通信信道。所有服务器3都连接到网关11。网关11可以连接到远程监视中心站13。信道10可以是有线或无线信道,并且可以确保大带宽,例如它们可以形成TCP/IP网络(例如,以太网、Wi-Fi等)。小带宽信道9(例如无线连接信道)可以将每个客户端5连接到相应的服务器3,服务器3包括用于连接到客户端5的相关接入点。
本文公开的方法的一个方面涉及客户端5连接到相应服务器3以实现最佳负载平衡的方式。本文公开的方法的其它方面涉及动态调整多客户端/多服务器系统1的配置例如以适应可能影响传输信号强度的可变环境条件或可能使得一个或多个服务器3不起作用的事件的方式。
如上面所提到的,客户端5可以是任何类型的电子设备。在本文描述的示例性实施例中,一些客户端5是光伏面板装置的逆变器或微型逆变器。还应该理解的是,客户端5可以是相同类型或类别的电子设备(例如,所有逆变器或微型逆变器),或者它们可以包括不同类型的电子设备,例如组合起来的逆变器、中继器、网络扩展器、传感器等。
逆变器或微型逆变器具有电连接到光伏面板的输入端子和电连接到配电网的输出端子。由光伏面板生成的DC电流通过微型逆变器转换成AC电流。AC电流被输送到配电网以便为本地负载供电和/或用于分配到公共配电网。图2示意性地图示了由多排光伏面板15组成的光伏设备的一部分,每个光伏面板15连接到相应的逆变器或微型逆变器5(5.i,5.i+1,5.i+2,…)。客户端5(例如,逆变器、微型逆变器或其它电子设备)电连接到配电网17,并且每个微型逆变器5与至少一个服务器3(3.i、3.j)处于数据通信关系。
根据一些实施例,每个客户端5可以采取若干状态并执行若干动作,以便加入客户端/服务器网络。图3示意性地图示了每个客户端5可以采取的四种状态。箭头示意性地表示客户端5可以执行以从一种状态切换到另一种状态的动作。图3中表示的四种客户端状态定义如下:
-IDLE(空闲):这是在链接到网络1之前客户端5的状态,例如,当它首次从工厂交付并安装在系统1中时,或者一旦它被重置为出厂默认值。如稍后将解释的,根据一些实施例,这种状态可以由网络的服务器强制执行;即,客户端5可以被它先前已连接到的服务器3强制返回到IDLE状态;
-JOINED(已加入):这是客户端5连接到相应服务器3并且通过所述服务器3与远程监视中心站13连接的状态。客户端5与远程监视中心站13进行数据通信,并且可以发送/接收数据、命令或指令。每个服务器3可以由服务器标识号识别。例如,服务器3.j可以由标识号ID_server_j识别。一旦加入到服务器3.j,通用客户端5.i就将能够仅与所述服务器通信,除非采取特殊的重置动作,如下面将公开的。网络或系统1又可以由网络标识号ID_Network识别;
-ORPHAN(孤立):如果出于某种原因客户端5和相关服务器3之间的通信丢失,那么客户端5将被设置为ORPHAN状态。这可以例如由于由暂时环境干扰因子造成的无线通信网络中通信信号的丢失而发生。例如,客户端5也可以由于到客户端5和/或到相应服务器3的电源暂时丢失而被设置为ORPHAN状态。在太阳能设备中,所有客户端5将在日落时切换到ORPHAN状态,因为电力供应中断将关闭网络。如果没有风,类似的情况可以发生在例如风力涡轮机装置中;
-SERVICE(服务):在这个状态下,客户端5需要来自工厂管理人员的服务干预。
如图3中的箭头示意性地表示的,每个客户端5可以从一个状态移到另一个状态。例如,处于IDLE状态的客户端5可以通过“第一次加入”动作切换到JOINED状态。在一些实施例中,客户端5可以通过重置动作从JOINED状态切换回IDLE状态。根据图3的示意图,客户端5也可以从SERVICE状态切换回IDLE状态。处于JOINED状态的客户端5可以切换到ORPHAN状态,例如,如果网络丢失,即,无论出于何种原因,如果客户端5与客户端5被连接到的所选服务器3之间的通信被中断。从ORPHAN状态,客户端5可以切换回JOINED状态或SERVICE状态。从SERVICE状态,设备5可以切换到IDLE状态或切换回ORPHAN状态。现在将更详细地描述这些切换动作。可以在本文公开的系统的一些示例性实施例中提供上面提到的状态和动作。在其它实施例中,可以提供不同数量的状态(例如,更少)和/或可以预见用以从一个状态切换到另一个状态的不同的动作集合。
处于IDLE状态的每个客户端5必须加入网络1的服务器3以开始与其通信并与网关11通信。如上所述,IDLE状态与ORPHAN状态不同,因为IDLE状态由从未加入网络或系统1或已被重置的客户端5采取。相反,ORPHAN状态由已经丢失与之前连接到的服务器3的连接的客户端5采取。
当首次建立系统或网络1时,所有客户端5都处于IDLE状态并且必须切换到JOINED状态。如果系统1被扩展,例如如果将附加的光伏面板和相关的微型逆变器(或其它通用电子设备,诸如传感器、中继器等)添加到网络或系统1,那么每个新添加的客户端5将处于IDLE状态并应通过与可用服务器3之一建立通信来加入系统1。
为了在处于IDLE状态的客户端5与服务器3之间建立新连接,根据一些实施例,处于IDLE状态的客户端5将发送连接到服务器3的重复请求。连接到服务器3的请求可以是寻址到网络1的所有服务器3的广播消息。当服务器3从客户端5接收到连接请求时,服务器3必须决定是否可以接受连接请求。根据一些实施例,提供了一种例程,用于根据连接策略建立客户端-服务器连接。本文公开的实施例提供了允许在系统1的各种服务器3之间平衡分配客户端5的例程。
根据一些实施例,从处于IDLE状态的客户端5接收连接请求的每个服务器3计算品质因数(下文中也简称为FoM),基于该品质因数,计算与发出请求的客户端5建立连接的概率。在当前优选的实施例中,FoM是基于多于一个因子计算的,例如依赖于服务器的因子和依赖于客户端的因子,或者依赖于客户端的因子和依赖于传输信道的因子,或者依赖于服务器的因子和依赖于传输信道的因子,或两个以上因子的组合。每个因子可以表述为百分比,即,其值可以在0到99之间。
一般而言,依赖于服务器的因子是任何因子,其取决于服务器3的一个或多个条件、参数或状态。根据一些示例性实施例,依赖于服务器的因子可以考虑可用时隙的数量,即,服务器3可以支持的可能服务器-客户端连接的总量减去已经连接到所述服务器3的客户端5的数量。如果N是可用时隙的总数并且M是已经加入服务器3的客户端5的总数,那么可用时隙的数量是N-M。例如,如果可用时隙的数量N是30并且已经连接到所述服务器3的客户端5的数量M是10,那么用于计算FoM的依赖于服务器的因子可以是接受如下定义的新连接的概率
另一个依赖于服务器的因子可以是服务器响应时间。还有另一个依赖于服务器的因子可以包括流量量和/或存储在服务器中的数据量。
依赖于客户端的因子是任何因子,其取决于客户端5的一个或多个条件、参数、状态。根据本文公开的示例性实施例,依赖于客户端的因子可以是由那个具体客户端5已经发送的不成功的连接请求的数量。
每个服务器3可以包括用于给定客户端5的计数器,该计数器在每次接收到来自那个客户端5的请求并且那个客户端未被服务器接受时增加,并且可以周期性地(例如,作为时间的函数)减小。
根据本文公开的实施例,每个客户端5.j可以由客户端标识号ID_client_j识别。所述ID_client_j标识号可以与连接请求一起发送,使得接收连接请求的任何服务器3也可以识别哪个客户端5正在发送连接请求。以这种方式,每个服务器3可以被编程为存储由每个客户端5接收的连接请求的数量。
在其它实施例中,每个客户端5可以包括计数器,其计数由那个客户端5生成的连接请求的数量,所述信息与连接请求一起被发送。因此,每个服务器3将被告知由给定客户端5生成的连接请求的数量,并且可以使用所述数量作为依赖于客户端的因子来计算FoM。
另一个依赖于客户端的因子可以是由客户端生成的数据的种类和数量。如上所述,客户端5不需要彼此完全相同,甚至可以属于不同类别的设备。逆变器和微型逆变器是生成大量数据的典型客户端,而传感器是生成较少数据的客户端。因此,在FoM计算中考虑的因子可以是由客户端生成的数据流量的强度。已经处理了大量数据的服务器可以为作为低流量发生器的客户端计算更高的FoM,并且如果客户端是高流量发生器,那么计算更小的FoM。
在客户端5和服务器3之间建立连接的目的之一是经由信道9、服务器3、信道10和网关11将客户端5收集的数据发送到远程监视中心站13。在一些实施例中,每个客户端5可以包括缓冲存储存储器,其中暂时存储数据。例如,如果客户端5是光伏系统的微型逆变器或任何其它通用电子设备,那么缓冲存储存储器可以根据时间存储与设备相关的关于电压、电流、功率、温度或其它操作参数或者事件的状态、警报、日志的数据。可以周期性地对数据进行采样,以根据时间收集关于上面提到的参数的信息。
由于客户端5必须连接到服务器3以便将数据发送到远程监视中心站13,因此用于计算FoM的取决于客户端的因子可以包括可用于那个特定客户端5的缓冲存储存储器。可用缓冲存储存储器越小,那个具体客户端5加入服务器3的概率就越大,反之亦然。换句话说,具有较少可用存储存储器的客户端5优先于具有较大可用缓冲存储存储器的客户端5,以避免丢失所收集的数据。因此,可用的缓冲存储存储器可以用作依赖于客户端的因子来计算品质因数。客户端5可以将关于可用缓冲存储存储器的信息连同连接请求一起发送到服务器3。
依赖于传输信道的因子是任何因子,其取决于传输信道9的一个或多个条件、参数、状态。例如,传输信号的强度可以用作指示传输质量的参数。特别是在无线传输的情况下,诸如天气条件、外部电磁噪声源等的环境条件会强烈地影响由客户端5发送并由服务器3接收的无线电信号的强度。一般而言,加入接收来自给定客户端5的最强信号的服务器3可以有助于传输带宽的最佳利用,因为一般而言优选的是客户端5加入可以与其建立最佳数据通信条件的那个服务器3。因此,用于计算FoM的依赖于传输信道的因子可以是由服务器3接收的信号的强度。
例如,如果最大接收信号强度指示(RSSI)为200并且客户端的最大RSSI为150,那么可以将依赖于传输信道的因子计算为
根据另外的实施例,依赖于传输信道的因子是每个服务器3在通信网络中“嗅探”的客户端的数量。这可以帮助服务器确定其它服务器执行客户端管理的人员和方式,并做出适当的明智决策。
上面提到的两个或更多个因子可以彼此组合使用。可以使用不同因子的不同组合。
在一些实施例中,用于计算FoM的一个、一些或全部因子可以用恒定或可变的权重加权,使得所述多个因子中的一个或另一个可以对所得的FoM具有更强的影响。
举例来说,令A、B和C是有助于计算品质因数的因子,其中:
A是依赖于服务器的因子,例如可用时隙的数量;
B是依赖于客户端的因子,例如客户端5已经发出的不成功连接请求的数量;
C是依赖于传输信道的因子,例如由服务器3从客户端5接收的信号的强度。
FoM可以计算为A、B、C和相关权重的函数f,如下所示:
其中α、β、γ是应用于A、B和C的权重。应该理解的是,可以使用多于一个依赖于服务器的因子、一个依赖于传输信道的因子和一个依赖于客户端的因子。在更简单的实施例中,可以仅使用所述因子A、B、C中的一个或两个。在更复杂的实施例中,可以组合使用多于三个因子,每个因子具有或不具有权重。在更进一步的实施例中,每个因子可以具有相同的权重,即,α=β=γ=1。
在一些实施例中,权重α、β、γ可以是常数。但是,在其它实施例中,权重α、β、γ中的一个、一些或全部可以是变量。例如,如果可用时隙的数量特别高,即,如果客户端5的数量远远少于那个特定服务器3中可用的时隙,那么由服务器3应用于因子A的权重可以高。但是,如果客户端的数量增加,例如随着更多客户端5被添加到系统1,那么可以减少应用于因子A的权重。
根据一些实施例,一个或多个服务器3可以彼此连接,使得可以在服务器3之间交换信息。虽然网络1的所有服务器3不必处于相互数据通信关系,但是在某些条件下,所有服务器3之间的通信可以是有用的。服务器3之间的通信可以通过信道9获得。因此,当由服务器3从客户端5接收到连接请求时,每个服务器3可以使用来自网络1的其它服务器3的数据计算FoM。因此,根据一些实施例,可以在计算FoM时使用另外的依赖于服务器的因子,该因子可以取决于在相互数据通信关系中在服务器之间交换的信息。
根据示例性实施例,如果网络1的所有服务器3处于相互数据通信关系,那么可以知道已连接客户端5的总数(即,处于JOINED状态的客户端5的总数)。在一些实施例中,信息可以更加详细,并且可以包括连接到每个服务器3的客户端5的数量。然后,FoM可以解决其中接收到连接请求的服务器3确定已连接到其的客户端5的数量大大低于(或者大大高于)连接到其它服务器的客户端的数量的情况。这个信息可以用作计算FoM的因子。在一些实施例中,如果服务器3确定连接到其的客户端5的数量低于连接到其余服务器的客户端5的平均数量,那么可以将高值归因于FoM的计算中涉及的因子。在相反的情况下将使用所述因子的低值。
根据一些实施例,服务器3之间的信息交换还可以用于评估哪个服务器3已经为给定的发出请求的客户端5计算出最高FoM,并且因此将与发出请求的客户端5建立连接。计算出最高FoM的服务器3将接受发出请求的客户端5并与其发起数据交换关系。
在一些实施例中,如果发出请求的客户端5发送广播连接请求,那么若干服务器3通常将接收该请求,并且它们中的每一个将计算相关的FoM。网络1可以被配置为比较由若干服务器3针对同一个连接请求计算的若干FoM。最高的FoM将自动确定哪个服务器3将接受发出请求的客户端5并与其建立连接。一个、一些或全部服务器3可以被配置为接收和比较来自多个服务器3的FoM。可替代地,诸如远程监视中心站13之类的专用设备可以负责建立哪个是最高的FoM。
用于连接请求连接的客户端5的例程可以例如提供以下步骤:
客户端发送连接请求,例如通过广播消息;
多个服务器3接收连接请求;
每个接收服务器3为发出请求的客户端计算品质因数FoM;
计算FoM交换信息的服务器确定哪个服务器计算出最高FoM;
具有最高FoM的服务器被通知它已被选择为必须与发出请求的客户端建立连接的服务器;
所选服务器3发出连接接受响应,从而识别服务器;
客户端接收连接接受响应并建立连接。
在其它实施例中,用于连接请求连接的客户端5的例程可以例如提供以下步骤:
客户端发送连接请求,例如通过广播消息;
多个服务器3接收连接请求;
每个接收服务器3为发出请求的客户端计算品质因数FoM;
计算FoM的每个服务器3将计算出的FoM发送给客户端5;
发出请求的客户端5确定哪个服务器已经计算出最高FoM并相应地通知服务器3;
在所选的服务器3和客户端5之间建立连接。
服务器3计算出的FoM越高,那个服务器与发出请求的客户端5建立连接的可能性越高。因此,由服务器计算出的FoM表示与服务器建立连接的概率。在其它实施例中,未提供最高计算出的FoM的选择。不管用于计算品质因数的方法如何,由服务器3计算出的FoM如下确定请求连接的客户端5被所述服务器3接受的概率。FoM可以包括在0和99之间,或者可以归一化到100,即,FoM表示发出请求的客户端5被服务器3接受的机会的百分比。从客户端5接收连接请求(即,加入请求)的每个服务器计算那个客户端的FoM。
可以使用若干可能的方式来将计算出的FoM用作客户端5被服务器3接受的概率的百分比。
在一些实施例中,每个服务器3可以包括随机数发生器,其生成包括在0和99之间的数字。一旦已经计算出FoM并生成随机数,就比较随机数与FoM。如果随机数包括在0和计算出的FoM之间,那么接受发出请求的客户端5,并且服务器3向发出请求的客户端5发送连接接受响应。如果生成的随机数高于计算出的FoM,那么不接受请求。在后一种情况下,可以将连接拒绝响应发送到发出请求的客户端5。
可替代地,服务器可以简单地不提供对请求的响应。在这两种情况下,来自发出请求的客户端5的请求被服务器3拒绝,或者主动通过连接拒绝响应,或者被动地(即,通过不响应请求)拒绝。
因此,由给定服务器3针对给定连接请求客户端5计算的FoM越高,那个客户端5接收连接接受响应的机会就越高。
根据其它实施例,外部参数(例如环境温度)可以用来代替随机数。可以使用提供高达百分之一摄氏度准确度的温度的温度传感器,并且可以将温度值的最后两位数与计算出的FoM进行比较。令XX.yy℃为测得的温度:将数字yy与计算出的FoM进行比较。发出请求的客户端5将如下接收连接接受响应或连接拒绝响应(其还可以包括没有来自服务器的响应的情况):
如果00≤yy≤FoM,那么发送请求接受响应
如果FoM≤yy≤99,那么不发送响应,或者发送请求拒绝响应。
基于上述例程,对于发送连接请求的处于IDLE状态的每个客户端5,没有、一个或一些服务器3将生成连接接受响应。如果没有服务器3生成连接接受响应,那么客户端5将发出新的连接请求,并且将重复上述例程。如果只有一个服务器3生成连接接受响应,那么客户端5将加入所述服务器3并开始与之通信。如果多于一个服务器3生成连接接受响应,那么客户端5将加入所述服务器之一。例如,客户端5可以加入服务器3,其的连接接受响应首先到达发出请求的客户端5或者决定哪个服务器被最佳“定位”以提供连接。可以使用若干方法来帮助做出这种决定(例如,RSSI、#所见的消息等)。
这些方法允许基于品质因数运行客户端接受例程,而无需比较由若干服务器3计算的FoM。FoM越高,连接到给定服务器3的机会越高。
如上所述,如果服务器3彼此通信,那么可以比较由若干服务器3针对请求连接的给定客户端5计算的FoM,并且与计算出最高FoM的服务器3建立连接。最高FoM的选择可以由服务器3执行,或者可以由远程监视中心站13执行。在进一步的实施例中,可以选择接收由若干服务器计算的FoM值并比较计算出的FoM以选择最高FoM的一个或一些服务器3作为主设备。
上述例程允许在系统1的若干服务器3之间平衡分配客户端5。接收连接接受响应并加入服务器3的客户端5从IDLE状态切换到JOINED状态。
连接接受响应可以包含服务器3.j的ID_server_j标识号。因此,客户端5.i将识别它加入到的服务器3.j。而且,客户端5.i加入到的服务器3.j可以被配置为接收和存储客户端5.i的ID_client_i标识号。以这种方式,每个服务器3生成并存储连接到其的所有客户端5的存储列表,并且所有客户端都存储相关的ID_server_j标识号。而且,如上所述,网络1可以由网络标识号ID_Network识别。每个服务器3和每个客户端5可以存储识别它被加入到的网络1的ID_Network。
如果连接丢失,那么这个信息对于客户端5.i重新加入服务器3.j是有用的。从下面的描述中可以明显看出,每个服务器3.j具有单义ID_server_j并不是必需的。实际上,在一些实施例中,给定系统的所有服务器3可以具有相同的ID_server_j标识码或标识号。根据其它实施例,每个服务器3j可以具有其自己的ID_server_j标识号并存储ID_Network标识号,以识别该服务器所属的网络1。
每当将新客户端5添加到系统或网络1时,例如当将新的光伏面板添加到太阳能设备(或者将任何其它电子设备添加到网络1)时,新添加的客户端5将处于IDLE状态并将开始加入可用服务器3之一的例程。到目前为止所描述的方法确保在服务器3之间正确分配客户端5,以获得公平的负载平衡并且还考虑可能影响传输信号强度的可能的环境条件。
一旦客户端5处于JOINED状态,多个事件会造成连接丢失。例如,天气条件(雪、雨或雾)可以对无线通信产生影响。类似地,电磁干扰会生成噪声,这会对客户端-服务器通信产生不利影响,并会导致断开连接。在太阳能设备中,由于电力供应中断,客户端和服务器将在日落时关闭。在风力涡轮机装置中,客户端和服务器可以在风停时关闭。在那些情况下,处于JOINED状态的一个、一些或全部客户端5将切换到ORPHAN状态。在图3的图中,这个事件由标记为“网络丢失”的箭头表示。
根据一些实施例,处于ORPHAN状态的客户端5.i将生成到其先前连接到的服务器3.j(即,到由标识号ID_server_j识别的服务器)的连接请求,因此,从ORPHAN状态重新加入不需要再次执行上述例程。
如上所述,更多服务器3可以具有相同的标识号ID_server_j。在这种情况下,处于ORPHAN状态的客户端可以加入由相同ID_server_j标识号识别的服务器中的一个或另一个。
为了使通用客户端5.i加入正确的服务器3.j,在具有相同ID_server_j标识码的几个服务器(即,在设置为ORPHAN状态之前其连接的服务器)中,可以使用存储在服务器中的数据。如上所述,每个服务器3.j可以存储其连接到的每个客户端5.i的ID_client_i标识号。现在,如果处于ORPHAN状态的客户端5.i需要连接到由服务器标识号ID_server_j识别的(一个或多个)服务器,那么只有处于ORPHAN状态的发出请求的客户端5.i先前连接到的服务器3.j将再次接受客户端5.i并将其重新设置为JOINED状态。这允许使用具有相同ID_server_j标识号的多个服务器3,而没有任何错误地将客户端5.i重新加入服务器3.j的风险,因为每个服务器将仅重新加入在设置为ORPHAN状态之前连接到其的客户端5。
如果通过网络标识号ID_network识别设备,那么每个客户端5和每个服务器3可以具有存储在其中的网络标识号ID_network。请求从ORPHAN状态重新加入服务器的客户端5将发送重新加入的请求,该请求可以包含服务器标识号ID_server_j和网络标识号ID_network,使得接收请求的服务器可以立即识别发出请求的客户端5.i是否属于同一网络1。因此避免了属于相邻网络的客户端和服务器之间的错误关联。
在一些实施例中,ID_network标识号可以代替ID_server_j标识号使用,或与ID_server_j标识号组合使用。在这种情况下,ID_network标识号可以用于重新加入。因此,处于ORPHAN状态的客户端5可以加入网络1的任何服务器。接收连接请求的每个服务器可以被配置为仅当发出请求的客户端5.i在先前连接的客户端5列表中时才接受该请求。重新加入成为快速过程。
在其它实施例中,从孤立客户端5.i接收连接请求的服务器3.j可以起动FoM计算例程并确定是否接受发出请求的客户端,而不管所述客户端先前是否连接到所述服务器。当从ORPHAN状态再次切换到JOINED状态时,这将导致服务器之间的客户端重新分配。
根据一些实施例,该方法可以被配置为当服务器3.j永久或暂时不起作用时防止通信中断或恢复客户端5和远程监视中心站13之间的通信。例如,在故障或崩溃的情况下,服务器3.j可能永久地不起作用。服务器3.j可能暂时不起作用,例如,由于传输信道10或传输信道9上的干扰造成的暂时连接丢失。
如果至少两个服务器3.j(1)和3.j(2)共享相同的ID_server_j标识号,那么在其中一个所述服务器崩溃的情况下,与其连接的任何客户端5.i可以如下加入到具有相同ID_server_j的剩余服务器3.j(2)。在服务器3.j(1)崩溃后,与其连接的客户端5.i(1)切换到ORPHAN状态并开始发送加入请求。仍然可操作的服务器3.j(2)接收连接请求并确定发出请求的客户端5.i(1)不在连接到其的客户端列表中。服务器3.j(2)可以被配置为使得它将不接受发出请求的客户端5.i(1)直到给定的延迟时间Δt已经过去。一旦延迟时间Δt已经过去,服务器3.j(2)就将立即或在计算出FoM后接受发出请求的客户端5.i(1)。如果若干服务器3.j共享相同的ID_server_j标识号,那么所述服务器中的每一个将执行相同的例程。因此,在服务器3.j(1)崩溃后切换到ORPHAN状态的发出请求的客户端5.i(1)将逐渐重新加入其余服务器3.j中的一个或另一个,这些其余服务器仍然可操作且具有相同的ID_server_j标识号。
根据一些实施例,如果每个服务器3.j具有其自己的单义ID_server_j标识号,那么可以基于ID_network标识号或标识码运行上述重新指派过程。由于服务器3.j崩溃而切换到ORPHAN状态的客户端5.i将开始发送连接请求。其余服务器将确定该请求来自属于同一网络的客户端(这通过连接请求中包含的ID_network标识号证明)。在经过给定的延迟Δt后,可操作的服务器3将运行如上所述的FoM计算例程,以将发出请求的客户端加入新服务器3。
在严重崩溃情况下客户端重新指派的结果在图4中以图形方式表示。在这个示例中,假设服务器3.2被损坏。属于组6.2的客户端5.i-5.j被部分地重新指派给服务器3.1并且部分地重新指派给服务器3.3。
上述状态/动作方案提供了附加的防盗功能。如果客户端-服务器连接丢失,例如因为客户端被欺骗性地从系统1中移除,那么客户端5将切换到ORPHAN状态并且不会加入另一个网络或系统1的服务器,并因此变得不可用。
根据一些实施例,每个服务器3可以包含关于属于系统1的所有客户端5的信息。在一些实施例中,可以在每个服务器3中或在一些所述服务器中为此目的提供存储存储器。这可以通过在每个服务器中手动加载ID_client_j标识号或者通过从远程监视中心站13通过网关11和信道10向每个服务器3发送所述信息来完成。因此可以实现两个附加功能。
一方面,防盗功能被添加到服务器3。每个服务器3只能接受它所属的网络或系统1的客户端5,并且如果在不同的系统中被引入则将变得无用。而且,如果两个系统安装在一定距离处,使得一个系统的客户端5可以被邻居系统的服务器3“看到”,那么第一系统的客户端5到第二系统的服务器的重叠或错误指派是不可能的,或者反之亦然。
如果由客户端5在ORPHAN状态下生成的重新加入服务器的请求不会导致重新建立连接,例如,因为服务器3坏了并且上述重新指派例程没有正确操作或者没有被提供,或者出于其它原因,那么客户端5可以从ORPHAN状态切换到SERVICE状态,如图3中所示。这可以在预设超时后发生。处于SERVICE状态的客户端5可以被重新设置在IDLE状态下。
根据一些实施例,客户端5可以被配置为使得它们在给定时间段之后切换回ORPHAN状态。图3中ORPHAN状态和SERVICE状态之间标记为“超时”的两个箭头指示客户端5可以在ORPHAN状态和SERVICE状态之间来回切换。如果使客户端5切换到ORPHAN状态的事件停止,那么客户端5因此可以再次连接到其服务器3。例如,如果损坏的服务器3被新服务器3替换,并且如果新服务器3被给予相同的ID_server_j标识号,那么先前加入到损坏的服务器的所有客户端5将加入替换服务器3。
如果客户端5被设置为处于SERVICE状态并且不能再次连接到其服务器3,例如,因为服务器坏了并且没有被替换并且没有提供到不同服务器的重新指派路由或者没有正常操作,那么可以在远程监视中心站13处检测到异常情况,例如由于不再接收来自所关心的客户端5的数据。然后可以触发手动服务干预。在一些实施例中,服务干预可以由负责系统1的人员执行。处于SERVICE状态但未成功返回JOINED状态的客户端5被手动重置为IDLE状态。这个动作由图3中的箭头“重置”示意性地表示,该箭头将SERVICE状态与IDLE状态相连接。一旦客户端5已经被重置为IDLE状态,它就将执行上述用于加入新服务器3的例程。
例如,还可以改进上述操作方法以应对可变网络条件。如上所述,天气或其它因素(诸如电磁噪声等)可以对信号的强度产生影响。条件可以在时间期间改变,以至于在经修改的条件下未优化所选的客户端-服务器连接。
可以影响或修改系统操作的其它因素包括向网络1添加新客户端5。每个新添加的客户端5可以通过FoM计算例程通过如上所述从IDLE状态切换到JOINED状态来加入网络1。但是,如果未修改已经建立的客户端-服务器连接,那么很可能发生在添加多个客户端5时实现的系统配置未被优化。换句话说,如果通过添加元件或部件(或者服务器,或者更常见的是客户端)来扩大系统或网络1,那么客户端和服务器的不同分布可能导致更平衡的网络。
本文公开的方法的改进实施例提供了用于动态地使系统1的配置适应于例如修改后的操作条件或客户端5的数量的手段。
根据所述实施例,每个服务器3可以拒绝指派给它的一个或多个客户端5,并将所述(一个或多个)客户端重置为IDLE状态。这个动作在图3的方案中由通用客户端5的JOINED状态和IDLE状态之间标记为“重置”的箭头表示。这个功能允许修改客户端-服务器连接并动态调整系统以适应可变条件。
IDLE状态下的拒绝功能和随后的重置可以用于实现不同的目标,如将在这里描述的。
例如,它可以用于管理多个客户端5,其大于可用的总时隙,即,可连接到服务器3的客户端的总数。在图1的示意图中,提供了四个服务器3。假设每个服务器3可以管理30个客户端5,那么可以通过服务器3同时连接到网关11的客户端5的最大数量是120。如果客户端5的总数大于120,那么拒绝和重置功能可以用于循环拒绝一个或多个客户端,并允许来自等待列表的其它客户端5加入拒绝服务器3。
拒绝和重置功能还可以用于管理一些情况,其中客户端5的数量足够小以便由网络1中提供的服务器3管理,但是一个或多个服务器3暂时或永久不可用,例如,由于崩溃或故障。如上所述,可以提供由于服务器崩溃而切换到ORPHAN状态的客户端5的重新指派,以将处理ORPHAN状态的客户端5分配给新服务器3。但是,总可用时隙的数量可以变得小于要连接的客户端5的总数。
拒绝和重置功能还可以用于重新布置服务器-客户端连接,以考虑可能的可变环境条件、活动客户端5的总数的可变性,或可能影响网络1的整体结构或操作的任何其它动态事件。
在简单的实施例中,例如,在最大连接时间到期后,可以循环地拒绝连接到服务器3的每个客户端5。被拒绝的客户端5在IDLE状态下被重置并且将开始再次加入服务器3的例程。新建立的连接可以与前一个连接相同,即,客户端5可以加入相同的服务器3。可替代地,客户端5可以加入不同的服务器3。这将取决于在客户端5发出连接请求时系统或网络1的实际情况。
重新加入可以通过如上所述的FoM计算例程。
根据其它示例性实施例,由服务器3计算拒绝品质因数(这里简称为FoMR),以确定与其连接的客户端5是否以及其中的哪一个客户端5将被拒绝并且被重置在IDLE状态中。可以基于一个或多个因子计算FoMR。FoMR确定给定客户端5被相应服务器3拒绝并被重置在IDLE状态中的概率。
根据一些实施例,可以基于其计算用于客户端5的FoMR的一个因子基于从所关心的客户端5接收的信号的强度。信号的强度可以被表述为RSSI。根据一种方法,对FoMR的贡献越低,RSSI越高。这意味着服务器3从其接收到弱信号的客户端5具有较高的被拒绝概率百分比。根据这个方法,系统将尝试重新分配客户端5以获得改进的连接信号。由于信号的强度可以根据事件(诸如环境条件)而变化,因此针对给定客户端5计算的FoMR可以在时间期间变化。可以以规则或随机的间隔周期性地计算FoMR,并且对于相同的客户端5,FoMR可以改变。
根据一些实施例,可以基于其计算FoMR的另一个因子考虑缓冲存储存储器的量,该缓冲存储存储器可用于给定客户端5收集数据。由于处于空闲状态的客户端5不能通过服务器3将数据从其缓冲存储存储器传送到网关11,因此可用于数据存储的空间越小,给定客户端5被拒绝并被重置在空闲状态下的可能性就越小。这个因子考虑了避免数据丢失的需要。
根据还有另外的实施例,可以基于其计算用于给定客户端5的FoMR的另一个因子是客户端5的先前状态的函数。如果所关心的客户端5在接收到加入服务器3的连接接受响应之前已经处于IDLE状态长时间,那么再次设置在IDLE状态的概率应该为低。这种因子旨在使属于网络1的各种客户端之间的连接缺乏时间尽可能均匀,并且避免一些客户端5将比其它客户端更长时间保持在IDLE状态的情况。
至于FoM,FoMR也可以基于组合使用的一个、两个或更多个因子来计算。每个因子可以被加权,并且每个权重可以或者是常数或者是变量。在一些实施例中,一个或多个权重可以是一个或多个其它权重或因子的函数。
因此,一般而言,FoMR可以是一个或多个因子A'、B'、C'的函数(g)。每个因子可以用权重α'、β'、γ'加权。因此,FoMR可以表示为:
根据一些实施例,用于拒绝客户端5并将所述客户端5重置为IDLE状态的例程类似于用于将客户端5从IDLE状态切换到JOINED状态的例程。对于给定的客户端,计算FoMR并给出介于0和99之间的值。以任何合适的方式生成0到99之间的数字,例如,通过随机数生成器,并且比较两个实体。如果随机数包括在0和FoMR之间,那么客户端5被拒绝,否则它仍然加入到服务器3。由于被拒绝的客户端5处于IDLE状态,因此它将开始再次加入服务器3的过程。
根据一些实施例,服务器3可以为连接到其的每个客户端计算FoMR,并拒绝已经计算出最高FoMR的客户端5。
如果服务器处于相互数据通信关系,那么根据一些实施例,可以在多个服务器3之间协调拒绝策略。在一些实施例中,将基于计算出的FoMR并通过比较加入到不同服务器的客户端5的FoMR来选择性地拒绝客户端5。因此可以设想比较由若干服务器3计算出的FoMR,并且拒绝连接到各种服务器(或所述客户端中的一些)的所有客户端5当中具有(一个或多个)较高FoMR的(一个或多个)客户端。在这种场景下,被每个服务器3拒绝的客户端的数量可以随服务器不同而不同。在其它实施例中,可以提供调节功能,使得除了选择要被拒绝的客户端5之外,还可以设置可以被同一服务器3拒绝的客户端的最大数量的阈值。
由于客户端5被拒绝并被重置在IDLE状态下,因此网络1能够管理大于可用时隙总数的多个客户端5。在这种情况下,总是存在请求连接到服务器的处于IDLE状态的排队客户端5的等待列表。排队客户端5的数量Q通常等于客户端5的总数减去可用时隙的总数。但是,这不是强制性的。在一些条件下,例如,如果暂时无法到达一个或多个服务器3,排队客户端的数量可以更高。
因此,例如,N个服务器3有可能管理多个客户端5,其数量大于可用的总时隙数。可以为每个服务器3先验地设置拒绝频率,或者可以根据需要改变拒绝频率。例如,拒绝频率(即,每个服务器3通过将客户端5重置为IDLE状态来拒绝客户端5的频率)可以取决于超过总可用时隙的系统的客户端5的数量(即,排队客户端5的数量)。
在一些实施例中,可以基于连接到服务器3的客户端5的总数来确定拒绝频率。连接的客户端数量越大,拒绝频率越高。
在一些实施例中,如果服务器3彼此通信,那么可以根据若干服务器之间的客户端的实际分布来调制每个服务器3的拒绝频率。例如,具有连接到其的更大量客户端5的服务器3可以被给予更高的拒绝频率,并且具有连接到期的更少量客户端5的服务器3可以被给予更低的拒绝频率。
根据本文公开的方法的示例性实施例,可以采取措施来减少排队时间。根据一些实施例,请求重新加入服务器3的排队客户端5的数量可以用于加速拒绝率。已被重置为IDLE状态并且等待重新加入服务器3的客户端5的数量越大,拒绝率越高,以提供更快的客户端流并缩短等待时间。处于故障状态的服务器3的存在也可以用于增加拒绝率。在这两种情况下,考虑到上述条件的因子可以添加在用于计算FoMR的公式中。
在上述场景中,通过将客户端从JOINED状态切换到IDLE状态来确定拒绝客户端5。但是,在其它实施例中,可以通过将客户端5从JOINED状态切换到ORPHAN状态来确定拒绝。具体而言,如果一些或全部服务器3由相同的ID_server_j标识号识别,或者如果使用公共ID_network标识号,那么,即使客户端5被切换在ORPHAN状态而不是IDLE状态下,网络1的动态调整通过循环的拒绝和重新加入也是可能的。
根据一些示例性实施例,如果服务器3.j的子组共享相同的ID_server_j标识号,那么通过将客户端5切换为ORPHAN状态而被服务器3.j拒绝的客户端5将被重新加入所述子组的服务器之一。
如果网络1的所有服务器具有相同的ID_server_j标识号,或者如果使用ID_network标识号(其对于所有服务器是相同的)而不是ID_server_j标识号,那么被拒绝并切换到ORPHAN状态的每个客户端5将起动加入服务器3的例程,并且可能能够加入网络1中的任何一个服务器3。
如上所述,根据一些实施例,服务器3可以彼此通信。服务器3之间的相互通信的一个目的可以是设置和/或修改用于计算FoM和/或FoMR的策略。例如,服务器3可以彼此通信以设置用于计算FoM和/或FoMR的适当权重。
根据示例性实施例,服务器3可以彼此通信,以便向每个服务器3通知系统1中的客户端5的总数,或者处于JOINED状态的客户端的总数。每个服务器3还有可能知道有多少客户端5与每个其它服务器3处于数据通信关系。例如,可以使用这个信息,以便在发现不平衡情况时起动拒绝例程。具有较高负载(即,连接到其的客户端5的数量较大)的服务器3可能被迫发起或加速拒绝策略。如果一个或多个服务器3与其它服务器3相比连接到过多的客户端,那么拒绝策略可以帮助重新平衡客户端-服务器连接的分配。
而且,根据一些实施例,服务器3使用服务器3之间的数据通信来检查其打算拒绝的客户端5是否可以被另一个服务器接受,并且可以基于取决于客户端5加入另一个服务器3的概率的因子来计算FoMR。例如,可以使用传输信道嗅探技术来确定其余服务器中有多少可以“看到”即将被拒绝的客户端5。根据一些实施例,拒绝服务器3可以确定是否其它服务器3具有可用于接受即将被拒绝的客户端5的时隙以及有多少其它服务器3具有可用于接受即将被拒绝的客户端5的时隙。可以考虑这个因子来计算FoMR。
根据示例性实施例,来自其它服务器3的数据可以用作计算FoM或FoMR的另外的依赖于服务器的因子。例如,如果处于IDLE状态的客户端5正在请求连接,那么由接收该请求的服务器3计算的FoM可以考虑已经有多少其它客户端5加入其余服务器3。如果计算FoM的服务器3具有已连接到其的多个客户端5,其数量低于连接到每个其余服务器3的客户端5的平均数量,那么FoM将相应地增加。如果已经连接到所述服务器3的客户端5的数量高于连接到剩余服务器3的客户端5的平均数量,那么FoM将减小。
根据一些实施例,服务器3被配置为周期性地检查系统的每个服务器3是否可操作。示例性实施例提供用于此目的的例程。如果检查例程成功完成,那么所有服务器3都在操作。如果一个服务器3损坏,那么可以获得关于损坏的服务器的信息。
在一些实施例中,检查例程包括发送广播检查消息。每个服务器3回复检查消息。如果缺少响应,那么服务器3损坏。系统1的服务器3之一可以被配置为主设备以执行这个例程。主设备将广播检查消息并收集接收到的响应,每个其余服务器3一个响应。每个响应都包含足以识别响应服务器3的信息。如果一个或多个服务器3不回复检查消息,那么主设备可以警告远程监视中心站13。
根据其它实施例,检查例程可以通过远程监视中心站13运行。后者可以发送命令消息,要求所有服务器3提供指示其状态的响应。损坏的服务器3将不响应。
如果服务器3具有自测能力,那么还可以在远程监视中心站13处收集关于不正常工作的服务器3的问题的信息。因此可以对服务干预进行编程。
根据一些实施例,远程监视中心站13可以被编程为确定是否从网络1的每个服务器3接收常规数据流。来自一个服务器3的数据流的缺失或更改的数据流可以被解释为对可能的服务器故障的警报。远程监视中心站13可以被编程为在所关心的服务器上执行状态检查。
根据示例性实施例,由远程监视中心站13检测到的关于网络1的服务器3之一的异常情况可以起动客户端重新指派例程。在一些实施例中,客户端重新指派例程由远程监视中心站13控制。将信息发送到指派给故障或损坏的服务器3的客户端5应被重新指派给的其余服务器3。从先前指派给故障或损坏的服务器3的处于ORPHAN状态的客户端5接收请求的其余服务器3中的每一个将接受连接请求。重新指派的客户端5可以存储新服务器3的ID_server_j标识号,并且新服务器3将存储新连接的客户端5的ID_client_k标识号,以便将来从ORPHAN状态重新加入。
一旦损坏的服务器3被新服务器3替换,就可以起动重新平衡例程以重新平衡客户端分配。一旦更换了服务器3,远程监视中心站13就可以发送重新平衡例行命令。重新平衡例程可以涉及除了新替换的服务器之外的服务器的拒绝例程。处于JOINED状态的客户端5的拒绝将逐渐重新平衡服务器3之间的客户端分配。
Claims (16)
1.一种用于管理多客户端/多服务器系统(1)的方法,所述多客户端/多服务器系统(1)包括多个服务器(3)和多个客户端(5),每个客户端需要到所述服务器中的至少一个服务器的连接;所述方法包括以下步骤:
-当所述服务器(3)中的至少一个服务器从客户端(5)之一接收到连接请求时,服务器(3)计算发出请求的客户端的品质因数(FoM);其中,品质因数(FoM)确定发出请求的客户端(5)被加入到服务器(3)的概率。
2.如权利要求1所述的方法,还包括以下步骤:
-一旦服务器(3)计算出品质因数(FoM),服务器(3)就以取决于品质因数的概率将连接接受响应发送到发出请求的客户端(5);
-接收到连接接受响应的发出请求的客户端(5)加入服务器(3)并开始与之通信。
3.如权利要求1或2所述的方法,其中如果数个服务器(3)从客户端(5)接收到连接请求,则比较由所述服务器(3)计算的品质因数(FoM),并且发出请求的客户端(5)将被加入到已计算出最高品质因数(FoM)的服务器(3)。
4.如前述权利要求中的一项或多项所述的方法,包括关于以下因子的组合计算品质因数的步骤:服务器的可用时隙的数量;从发出请求的客户端到服务器的传输信号的强度;由客户端发出的连接请求的数量。
5.如权利要求4所述的方法,其中还关于指示发出请求的客户端的空闲数据缓冲存储器的量的因子来计算品质因数。
6.如权利要求4或5所述的方法,包括利用加权系数对至少一个因子加权的步骤,其中品质因数取决于所述至少一个因子。
7.如权利要求3至6中任一项所述的方法,包括利用加权系数对每个因子加权的步骤,其中品质因数取决于所述因子。
8.如权利要求6或7所述的方法,其中至少一个加权系数是常数。
9.如权利要求6或7或8所述的方法,其中至少一个加权系数是变量,并且优选地,所有加权系数都是变量。
10.如权利要求6至9中任一项所述的方法,其中至少一个因子的加权系数是其它因子中的至少一个的函数。
11.如前述权利要求中的一项或多项所述的方法,还包括在多个所述服务器(3)之间交换信息的步骤。
12.如权利要求11所述的方法,其中在多个服务器(3)之间交换信息的步骤包括以下步骤:比较由多个服务器(3)为发出请求的客户端(5)计算的品质因数;从已计算出最高品质因数的服务器(3)向发出请求的客户端(5)发送连接接受响应。
13.如前述权利要求中的一项或多项所述的方法,其中客户端(5)被配置为使得当客户端(5)已加入服务器(3)时,进一步的通信将仅通过客户端(5)已加入的服务器(3)进行。
14.如权利要求13所述的方法,包括以下步骤:拒绝连接到服务器(3)的客户端(5),将所述客户端置于非连接状态;并且由所述被拒绝的客户端(5)生成对于连接到服务器(3)的新请求。
15.如权利要求14所述的方法,包括以下步骤:为连接到所述服务器(3)中的至少一个服务器的多个客户端(5)计算拒绝品质因数(FoMR),每个所述拒绝品质因数确定相关客户端(5)被服务器(3)拒绝的概率。
16.如权利要求15所述的方法,其中作为以下因子中的一个或多个的函数来计算拒绝品质因数:客户端-服务器通信信号的质量;可用于客户端的缓冲存储器的量;排队以连接到服务器(3)的客户端(5)的数量;连接到系统(1)的服务器(3)的客户端(5)的总数;连接到服务器(3)的客户端(5)的总数。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2016/080811 WO2018108249A1 (en) | 2016-12-13 | 2016-12-13 | A multi-client/multi-server managing method and system |
Publications (1)
Publication Number | Publication Date |
---|---|
CN110178351A true CN110178351A (zh) | 2019-08-27 |
Family
ID=57589004
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201680091995.4A Pending CN110178351A (zh) | 2016-12-13 | 2016-12-13 | 多客户端/多服务器管理方法和系统 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20200036777A1 (zh) |
EP (1) | EP3556077A1 (zh) |
CN (1) | CN110178351A (zh) |
WO (1) | WO2018108249A1 (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117041317A (zh) * | 2023-10-09 | 2023-11-10 | 安徽隼波科技有限公司 | 一种基于FreeRTOS管理TCP多客户端之间连接的方法 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11153357B2 (en) * | 2017-10-25 | 2021-10-19 | Harman Professional, Inc. | System and method for allowing simultaneous TCP connections to a point-to-point TCP connected device |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7103809B2 (en) * | 2003-10-24 | 2006-09-05 | Motorola, Inc. | Server selection method |
US7231445B1 (en) * | 2000-11-16 | 2007-06-12 | Nortel Networks Limited | Technique for adaptively distributing web server requests |
EP1502198B1 (en) * | 2002-05-06 | 2008-02-27 | Nokia Corporation | A content delivery architecture for mobile access |
CN101778105A (zh) * | 2010-01-20 | 2010-07-14 | 杭州华三通信技术有限公司 | 获取基于web的实时性能监视指标数的方法、系统及设备 |
US20100179927A1 (en) * | 2009-01-12 | 2010-07-15 | Ca, Inc. | Rating risk of proposed system changes |
CN102123179A (zh) * | 2011-03-28 | 2011-07-13 | 中国人民解放军国防科学技术大学 | 应用于分布式应用系统的负载均衡方法和系统 |
US20140007179A1 (en) * | 2012-06-29 | 2014-01-02 | Microsoft Corporation | Identity risk score generation and implementation |
CN104995899A (zh) * | 2013-01-11 | 2015-10-21 | 微软技术许可有限责任公司 | 服务器负载管理 |
CN106101171A (zh) * | 2016-05-24 | 2016-11-09 | 中国联合网络通信集团有限公司 | 服务器连接方法及装置 |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6647424B1 (en) * | 1998-05-20 | 2003-11-11 | Nortel Networks Limited | Method and apparatus for discarding data packets |
US8613671B2 (en) * | 2009-06-08 | 2013-12-24 | Cfph, Llc | Data transfer and control among multiple computer devices in a gaming environment |
-
2016
- 2016-12-13 EP EP16815793.1A patent/EP3556077A1/en not_active Withdrawn
- 2016-12-13 CN CN201680091995.4A patent/CN110178351A/zh active Pending
- 2016-12-13 US US16/469,250 patent/US20200036777A1/en not_active Abandoned
- 2016-12-13 WO PCT/EP2016/080811 patent/WO2018108249A1/en unknown
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7231445B1 (en) * | 2000-11-16 | 2007-06-12 | Nortel Networks Limited | Technique for adaptively distributing web server requests |
EP1502198B1 (en) * | 2002-05-06 | 2008-02-27 | Nokia Corporation | A content delivery architecture for mobile access |
US7103809B2 (en) * | 2003-10-24 | 2006-09-05 | Motorola, Inc. | Server selection method |
US20100179927A1 (en) * | 2009-01-12 | 2010-07-15 | Ca, Inc. | Rating risk of proposed system changes |
CN101778105A (zh) * | 2010-01-20 | 2010-07-14 | 杭州华三通信技术有限公司 | 获取基于web的实时性能监视指标数的方法、系统及设备 |
CN102123179A (zh) * | 2011-03-28 | 2011-07-13 | 中国人民解放军国防科学技术大学 | 应用于分布式应用系统的负载均衡方法和系统 |
US20140007179A1 (en) * | 2012-06-29 | 2014-01-02 | Microsoft Corporation | Identity risk score generation and implementation |
CN104995899A (zh) * | 2013-01-11 | 2015-10-21 | 微软技术许可有限责任公司 | 服务器负载管理 |
CN106101171A (zh) * | 2016-05-24 | 2016-11-09 | 中国联合网络通信集团有限公司 | 服务器连接方法及装置 |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117041317A (zh) * | 2023-10-09 | 2023-11-10 | 安徽隼波科技有限公司 | 一种基于FreeRTOS管理TCP多客户端之间连接的方法 |
CN117041317B (zh) * | 2023-10-09 | 2023-12-08 | 安徽隼波科技有限公司 | 一种基于FreeRTOS管理TCP多客户端之间连接的方法 |
Also Published As
Publication number | Publication date |
---|---|
US20200036777A1 (en) | 2020-01-30 |
EP3556077A1 (en) | 2019-10-23 |
WO2018108249A1 (en) | 2018-06-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5606484B2 (ja) | 充放電制御装置、充放電制御システム及び充放電制御プログラム | |
CN104023357A (zh) | 集中式无线局域网的负载均衡方法及接入控制器 | |
US10362506B2 (en) | Communication aggregation system, control device, processing load control method and non-transitory computer readable medium storing program | |
US10257759B2 (en) | Load balancing among wireless access points | |
CN112055364B (zh) | 一种网络系统分级方法及装置 | |
CN102802202A (zh) | 终端站点接入方法、设备及系统 | |
CN110178351A (zh) | 多客户端/多服务器管理方法和系统 | |
US10559958B2 (en) | Method, controller, and network for controlling devices in power distribution network | |
CN107949048B (zh) | 基于云无线接入网络的调度方法及系统 | |
EP4236431A1 (en) | Cell site auxiliary equipment control | |
CN110178352A (zh) | 利用拒绝已连接客户端以平衡系统的例程的多客户端/多服务器管理方法和系统 | |
CN101841850A (zh) | 在lte系统中获取邻区负荷信息的方法、装置和系统 | |
US11716683B2 (en) | Method and system for aggregating power outage data and utilization | |
EP3783958B1 (en) | Wireless backhaul connection method and device | |
JP4633529B2 (ja) | 負荷分散方法、C−planeWirelessController装置、基地局および端末局 | |
US8036720B1 (en) | Method and system for conserving power in a telecommunications network during emergency situations | |
JP6396693B2 (ja) | 情報送受信システム、情報通信装置、管理装置、情報送受信方法、情報通信装置のプログラム及び管理装置のプログラム | |
CN105632152A (zh) | 电力用户用电信息抄读方法、系统及智能互动终端 | |
US20220255321A1 (en) | Server apparatus and management method | |
Nguyen et al. | A novel strategy for failure-tolerant communication in smart grids | |
CN113473406A (zh) | 一种实现设备管理的方法、装置、计算机存储介质及终端 | |
CN117880886A (zh) | 数据包的转发方法、装置、存储介质及电子装置 | |
WO2023072401A1 (en) | A wireless power transfer network with smart features | |
CN117220370A (zh) | 多个充电设备的功率管理方法、充电设备及充电站 | |
US20160286405A1 (en) | Working Node Determining Method, Apparatus, and Network Element, and EMS and NMS |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
TA01 | Transfer of patent application right | ||
TA01 | Transfer of patent application right |
Effective date of registration: 20201120 Address after: Rotterdam Applicant after: Marich holdings Netherlands Ltd. Address before: Baden, Switzerland Applicant before: ABB Switzerland Co.,Ltd. |
|
WD01 | Invention patent application deemed withdrawn after publication | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20190827 |