CN105763605B - 诊疗服务器系统及其通信方法 - Google Patents

诊疗服务器系统及其通信方法 Download PDF

Info

Publication number
CN105763605B
CN105763605B CN201610079434.4A CN201610079434A CN105763605B CN 105763605 B CN105763605 B CN 105763605B CN 201610079434 A CN201610079434 A CN 201610079434A CN 105763605 B CN105763605 B CN 105763605B
Authority
CN
China
Prior art keywords
server
data packet
access server
client
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.)
Active
Application number
CN201610079434.4A
Other languages
English (en)
Other versions
CN105763605A (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.)
Guiyang Longmaster Information and Technology Co ltd
Original Assignee
Guiyang Longmaster Information and Technology 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 Guiyang Longmaster Information and Technology Co ltd filed Critical Guiyang Longmaster Information and Technology Co ltd
Publication of CN105763605A publication Critical patent/CN105763605A/zh
Application granted granted Critical
Publication of CN105763605B publication Critical patent/CN105763605B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • G06F19/3418—

Abstract

本发明公开了一种诊疗服务器系统及其通信方法。上述系统包括：仅负责用户登录和注册业务的接入服务器；消息服务器,与所述接入服务器相连接；配置管理服务器，与所述接入服务器相连接；诊疗室管理服务器，与所述接入服务器相连接；其中，所述消息服务器、所述配置管理服务器以及所述诊疗室管理服务器之间相互独立。根据本发明提供的技术方案，接入服务器只负责登录及注册相关的业务功能，减轻接入服务器的负担，其它业务根据功能的不同，设计不同的独立服务器来处理，降低了耦合度，提高了服务器的健壮性。

Description

诊疗服务器系统及其通信方法
技术领域
本发明涉及通信领域，具体而言，涉及一种诊疗服务器系统及其通信方法。
背景技术
针对诊疗项目服务器业务复杂、耦合度高、特别用户有在线概念，当服务器出问题或更换服务器时会导致用户全部掉线，影响很大的问题，设计一种服务器架构，解决上述种种问题，使服务器不仅在开发维护，更甚在用户体验上带来很大的提升。
相关技术中，一个诊疗项目中单个服务器承载的业务多，且各个服务器之间有一定的耦合，这就导致牵一发而动全身，一个点出问题，会连锁反应引起其它模块的问题，严重的会导致整个服务器系统瘫痪，用户最终无法使用产品。
图1为根据相关技术的服务器架构的示意图。如图1所示，该服务器架构中，接入服务器(PES)臃肿复杂，为维护带来极大不便。PES2结构和PES1一样，随着用户量的上升，同样的问题是要面对的。从产品开发过程来看，随着用户量的上升，经常遇到，由于PES某功能模块或其自身，或者与数据库交互压力过大导致整个PES异常，同时定位困难，进而影响用户的使用。
发明内容
本发明的主要目的在于公开了一种诊疗服务器系统及其通信方法，以至少解决相关技术的服务器架构中，服务器业务复杂、耦合度高，当服务器出问题或更换服务器时会导致用户全部掉线，影响很大的问题。
根据本发明的一个方面，提供了一种诊疗服务器系统。
根据本发明的诊疗服务器系统包括：仅负责用户登录和注册业务的接入服务器；消息服务器,与所述接入服务器相连接；用户配置及账户管理服务器服务器，与所述接入服务器相连接；诊疗室管理服务器，与所述接入服务器相连接；其中，所述消息服务器、所述配置管理服务器以及所述诊疗室管理服务器之间相互独立。
根据本发明的另一方面，提供了一种诊疗服务器系统的通信方法。
根据本发明的诊疗服务器系统的通信方法包括：接入服务器基于TCP链接接收来自于客户端的第一数据包；所述接入服务器根据所述第一数据包中的包类型字节判断所述第一数据包为发送至配置管理服务器的数据包；所述接入服务器根据所述第一数据包中的queryID判断该数据包所属的配置管理服务器；所述接入服务器将所述第一数据包的头部去掉，套上数据后发送至所述所属的配置管理服务器。
根据本发明的又一方面，提供了一种诊疗服务器系统的通信方法。
根据本发明的诊疗服务器系统的通信方法包括：接入服务器基于TCP链接接收来自于客户端的第三数据包；所述接入服务器根据所述第三数据包中的包类型字节判断所述第三数据包为发送至诊疗室管理服务器的数据包；所述接入服务器根据所述第三数据包中的queryID判断该数据包所属的所述诊疗室管理服务器；所述接入服务器将所述第三数据包的头部去掉，套上数据后发送至所述所属的所述诊疗室管理服务器。
根据本发明的再一方面，提供了一种诊疗服务器系统的通信方法。
根据本发明的诊疗服务器系统的通信方法包括：接入服务器基于TCP链接接收来自于客户端的第五数据包；所述接入服务器根据所述第五数据包中的包类型字节判断所述第五数据包为发送至消息服务器的数据包；所述接入服务器根据所述第五数据包中的queryID判断该数据包所属的消息服务器；所述接入服务器将所述第五数据包的头部去掉，套上数据后发送至所述所属的消息服务器。
与现有技术相比，本发明实施例至少具有以下优点：提供了一种新的诊疗服务器系统架构，接入服务器只负责登录及注册相关的业务功能，减轻接入服务器的负担，其它业务根据功能的不同，设计不同的独立服务器来处理，降低耦合度，提高服务器的健壮性。
附图说明
图1为根据相关技术的服务器架构的示意图；
图2为根据本发明实施例的诊疗服务器系统的结构框图；
图3为根据本发明优选实施例的诊疗服务器系统的结构框图；
图4为根据本发明优选实施例的PES服务器负载均衡示意图；
图5为根据本发明优选实施例的UCS服务器负载均衡示意图；
图6为根据本发明优选实施例的DCMS服务器负载均衡示意图；
图7为根据本发明优选实施例的MSGS服务器负载均衡示意图；
图8为根据本发明优选实施例的诊疗服务器系统的架构图；
图9为根据本发明优选实施例一的诊疗服务器系统的通信方法的流程图；
图10为根据本发明实例的诊疗服务器系统的通信方法的流程图；
图11为根据本发明优选实施例二的诊疗服务器系统的通信方法的流程图；以及
图12为根据本发明优选实施例三的诊疗服务器系统的通信方法的流程图。
具体实施方式
下面结合说明书附图对本发明的具体实现方式做一详细描述。
图2为根据本发明实施例的诊疗服务器系统的结构框图。如图2所示，该诊疗服务器系统包括：仅负责用户登录和注册业务的接入(PES)服务器20；消息(MSGS)服务器21,与上述PES服务器20相连接；配置管理服务器(UCS)服务器22，与上述PES服务器20相连接；诊疗室管理(DCMS)服务器23，与上述PES服务器20相连接；其中，上述MSGS服务器21、上述UCS服务器22以及上述DCMS服务器23之间相互独立。
相关技术的服务器架构中，PES服务器臃肿复杂，为维护带来极大不便。如图1所示，本发明提供的新的诊疗服务器系统架构中，PES只负责登录及注册相关的业务功能，减轻PES的负担，其它业务根据功能的不同，设计不同的独立服务器来处理，降低了耦合度，提高了服务器的健壮性。
需要说明的是，上文提到的诊疗室管理服务器(DCMS)为主要负责管理所有频道的服务器。上文提到的配置管理服务器(UCS)为主要负责用户配置及账户管理的服务器。上文提到的消息服务器(MSGS)为负责消息处理及管理的服务器。上文提到的接入服务器(PES)为对用户进行接入的服务器，例如，该接入服务器为特定会员号段的用户提供服务，负责用户登录等逻辑功能。
优选地，上述PES服务器20可以进一步包括：第一接收模块(图3中未示出)，设置于接收来自于上述MSGS服务器21、上述UCS服务器22、和/或上述DCMS服务器23的数据；第一发送模块(图3中未示出)，与上述第一接收模块相连接，设置于将上述第一接收模块接收到的数据转发至客户端；第二接收模块(图3中未示出)，设置于接收来自于上述客户端的数据；第二发送模块(图3中未示出)，与上述第二接收模块相连接，设置于将上述第二接收模块接收到的数据转发至上述MSGS服务器、上述UCS服务器、和/或上述DCMS服务器。
由此可见，PES此时仅作为唯一入口，负责客户端登录后和各个业务服务器的交互，仅仅转发数据包而已，不做其它任何操作。
优选地，如图3所示，上述诊疗服务器系统还可以包括：一个或多个新业务服务器24(图3只示出一个)，均与上述PES服务器相连接，用于承载新增加的业务，其中，上述业务服务器、上述MSGS服务器、上述UCS服务器以及上述DCMS服务器之间各个服务器相互独立。
优选地，如图3所示，上述诊疗服务器系统还可以包括：客户端(CLIENT)25，与上述PES服务器相连接；网站(WEB)服务器26，分别与上述UCS服务器和MSGS服务器相连接。
优选地，如图3所示，上述诊疗服务器系统还可以包括：网守服务器(PGKS)27，与客户端相连接，用于为每个上述PES服务器均分配一个对应的用户标识userID区间段，并将用户所属的PES服务器的信息通知该用户的客户端。
需要说明的是，上述网守服务器(PGKS)负责用户注册、会员号分配等功能。
以下结合图4进一步描述上述优选实施方式。
如图4所示，PES服务器为用户登录的唯一入口，负责用户注册相关及登录的功能。服务器的使用每个账户的唯一标识为userID，每个userID是独立的，而从量的考虑来说，负载均衡的设计初衷在于，分担过多的压力，故通过userID段来规定每个业务服务器的处理范围，保证每个业务服务器都在处理能力范围之内，保证用户的正常使用。给每个PES服务器分配userID处理区间段，故当用户达到一定量时可以扩展一个新的PES服务器来处理增加的userID的操作请求，减轻前一个PES服务器的处理压力，进而实现PES服务器的负载均衡。
优选实施过程中，每个客户端从属哪个PES服务器从注册分配userID后就已经确定，除非更换userID登录操作。而分配userID属于哪个PES服务器由网守(PGKS)服务器来决定，故PES的负载均衡源头在网守服务器。一个新用户注册，PGKS服务器会分配一个userID给用户，此时PGKS会根据分配的userID号段归属通知客户端从属哪个PES服务器，实现PES服务器的负载均衡。
优选地，当上述UCS服务器、上述MSGS服务器、或上述DCMS服务器为多个，上述PES服务器20还可以包括：判断模块(图3中未示出)，连接于第二接收模块与第二发送模块之间，用于在接收到的需要发送给上述UCS服务器、上述MSGS服务器、或上述DCMS服务器的数据包中，根据查询对象标识queryID判断该数据包所属的UCS服务器、MSGS服务器、或DCMS服务器。
以下结合图5进一步描述上述优选实施方式。
如图5所示，UCS服务器主要交互对象为PES服务器，故负载均衡的设计主要在PES服务器上进行实现。
例如，设计的STRU_CLIENT_PES_FOR_UCS类型包：
上述queryID为实现负载均衡的关键。PES服务器会根据收到的queryID来判断操作对象归属于哪个UCS服务器，进而对应发送数据包，使每个UCS都在处理能力范围能运行。
同理，如图6所示，PES服务器也可以根据收到的queryID来判断操作对象归属于哪个MSGS服务器，进而对该所属的MSGS服务器发送数据包，使每个MSGS服务器在处理能力范围内都可以运行。
同理，如图7所示，PES服务器也可以根据收到的queryID来判断操作对象归属于哪个哪一个DCMS服务器，进而对该所属的DCMS服务器发送数据包，使每个DCMS服务器在处理能力范围内都可以运行。
以下结合图8进一步描述上述优选实施方式。
图8为根据本发明实例的诊疗服务器系统的架构图。如图8所示，该诊疗服务器系统将相关技术的PES服务器业务功能拆分出来，分布成多个独立的业务服务器，且各个服务器(MSGS服务器、UCS服务器、DCMS服务器)之间相互独立，没有耦合，例如MSG服务器和UCS服务器完全没有交互，彼此不会产生影响，PES服务器功能单一，仅负责登录及注册相关，如无修改，用户登录后除非自己下线，否则不会出现掉线的情况，就算业务需求修改其它业务，也不会对登录产生影响，修改的模块只影响自己，不会影响其它业务功能。PES服务器此时作为唯一入口，负责客户端登录后和各个业务服务器的交互，仅仅转发数据包而已，不做其它任何操作。新的业务需求，可以将之集成成一个或多个新的业务服务器，扩展进去，不会对原有产生影响；且拆分后的服务器，如UCS服务器，设计上做了扩展考虑，支持负载均衡，扩展完全没有问题。
图9为根据本发明优选实施例一的诊疗服务器系统的通信方法的流程图。如图9所示，该诊疗服务器系统的通信方法包括：
步骤S901：接入(PES)服务器基于TCP链接接收来自于客户端的第一数据包；
步骤S903：PES服务器根据上述第一数据包中的包类型字节判断上述第一数据包为发送至用户配置及账户管理服务器(UCS)服务器的数据包；
步骤S905：PES服务器根据上述第一数据包中的查询对象标识(queryID)判断该数据包所属的UCS服务器；
步骤S907：PES服务器将上述第一数据包的头部去掉，套上数据后发送至上述所属的UCS服务器。
基于上述诊疗服务器系统的通信方法中，减轻PES的负担，PES此时作为唯一入口，负责客户端登录后和各个业务服务器的交互，仅仅转发数据包而已，不做其它任何操作，提高了服务器的健壮性。PES服务器会根据收到的queryID来判断操作对象归属于哪个UCS，进而对应发送数据包，使每个UCS服务器都在处理能力范围能运行，实现负载均衡。
优选实施过程中，客户端通过TCP链接与PES服务器交互，客户端发送数据包到PES服务器，PES服务器对不用处理的业务包，进行回复，完成交互。
优选实施过程中，客户端通过PES服务器与UCS服务器交互，其中通信数据包的结构如下：
STRU_CLIENT_PES_FOR_UCS类型数据包：
如图10所示，PES收到客户端上行请求，若包类型为DEF_CLIENT_PES_FOR_UCS，则认为该包为客户端发送给UCS服务器的透传包，将包的头部去掉后，套上STRU_PES_COMMON_NESTING_PACKET发送到UCS服务器。包中会有queryID字段信息，便于以后用户量上去后，根据queryID段实现UCS的负载均衡。
优选地，上述诊疗服务器系统的通信方法还可以包括：上述PES服务器接收来自于UCS服务器的第二数据包；上述PES服务器根据上述第二数据包中的包类型字节判断上述第二数据包为发送至客户端的数据包；上述PES服务器根据上述第二数据包的包头中用户标识userID判断客户端的接收端口；上述PES服务器将上述第二数据包的包头去掉，发送至该接受端口。
在优选实施过程中，DEF_UCS_PES_FOR_CLIENT类型包：
如图10所示，PES收到UCS的消息包，若消息类型为DEF_UCS_PES_FOR_CLIENT，则认为该包为UCS服务器发送给客户端的透传包，根据包头中的userID获取端客户端的接收端口，然后去掉包头信息，将包转发至客户端。
STRU_PES_COMMON_NESTING_PACKET类型包：
PES服务器将收到的客户端数据包，去掉消息头之后，根据包序确定是发往UCS服务器的，套上STRU_PES_COMMON_NESTING_PACKET，发给UCS服务器。
图11为根据本发明优选实施例二的诊疗服务器系统的通信方法的流程图。如图11所示，该诊疗服务器系统的通信方法包括：
步骤S1101：接入服务器(PES)基于TCP链接接收来自于客户端的第三数据包；
步骤S1103：PES根据上述第三数据包中的包类型字节判断上述第三数据包为发送至诊疗室管理服务器(DCMS)的数据包；
步骤S1105：PES根据上述第三数据包中的查询对象标识queryID判断该数据包所属的上述DCMS；
步骤S1107：PES将上述第三数据包的头部去掉，套上数据后发送至上述所属的DCMS。
基于上述诊疗服务器系统的通信方法中，减轻PES的负担，PES此时作为唯一入口，负责客户端登录后和各个业务服务器的交互，仅仅转发数据包而已，不做其它任何操作，提高了服务器的健壮性。PES服务器会根据收到的queryID来判断操作对象归属于哪个DCMS服务器，进而对应发送数据包，使每个DCMS服务器都在处理能力范围能运行，实现负载均衡。
优选地，诊疗服务器系统的通信方法还可以包括：上述PES服务器接收来自于DCMS的第四数据包；上述PES服务器根据上述第四数据包中的包类型字节判断上述第四数据包为发送至客户端的数据包；上述PES服务器根据上述第四数据包的包头中用户标识userID判断客户端的接收端口；上述PES服务器将上述第四数据包的包头去掉，发送至该接收端口。
需要说明的是，客户端通过PES与DCMS的交互过程，具体可以参见图10，此处不再赘述。
图12为根据本发明优选实施例三的诊疗服务器系统的通信方法的流程图。如图12所示，该诊疗服务器系统的通信方法包括：
步骤S1201：接入(PES)服务器基于TCP链接接收来自于客户端的第五数据包；
步骤S1203：PES根据上述第五数据包中的包类型字节判断上述第五数据包为发送至用户配置及账户管理服务器消息MSGS的数据包；
步骤S1205：PES根据上述第五数据包中的查询对象标识queryID判断该数据包所属的MSGS服务器；
步骤S1207：PES将上述第五数据包的头部去掉，套上数据后发送至上述所属的MSGS。
基于上述诊疗服务器系统的通信方法中，减轻PES的负担，PES此时作为唯一入口，负责客户端登录后和各个业务服务器的交互，仅仅转发数据包而已，不做其它任何操作，提高了服务器的健壮性。PES服务器会根据收到的queryID来判断操作对象归属于哪个MSGS服务器，进而对应发送数据包，使每个MSGS服务器都在处理能力范围能运行，实现负载均衡。
优选地，上述诊疗服务器系统的通信方法还可以包括：上述PES接收来自于MSGS的第六数据包；上述PES根据上述第六数据包中的包类型字节判断上述第六数据包为发送至客户端的数据包；上述PES根据上述第六数据包的包头中用户标识userID判断客户端的接收端口；上述PES服务器将上述第六数据包的包头去掉，发送至该接收端口。
需要说明的是，客户端通过PES服务器与MSGS服务器的交互过程，具体可以参见图10，此处不再赘述。
综上所述，借助本发明提供的上述实施例，PES只负责登录及注册相关的业务功能，减轻了PES的负担，其它业务根据功能的不同，设计不同的独立服务器来处理，降低了耦合度，提高了服务器的健壮性。此外，PES会根据收到的queryID来判断操作对象归属于哪个UCS服务器、DCMS服务器、或MSGS服务器，进而对应发送数据包，使每个UCS服务器、DCMS服务器、或MSGS服务器都在处理能力范围能运行，实现了业务服务器的负载均衡。
以上公开的仅为本发明的几个具体实施例，但是，本发明并非局限于此，任何本领域的技术人员能思之的变化都应落入本发明的保护范围。

Claims (10)

1.一种诊疗服务器系统，其特征在于，包括：
仅负责用户登录和注册业务的接入服务器；
消息服务器,与所述接入服务器相连接，负责消息处理及管理的服务器；
配置管理服务器，与所述接入服务器相连接；
诊疗室管理服务器，与所述接入服务器相连接，负责管理所有频道的服务器；
网守服务器，与客户端相连接，用于为每个所述接入服务器均分配一个对应的用户标识userID区间段，并将用户所属的接入服务器的信息通知该用户的客户端；
其中，当所述配置管理服务器、所述消息服务器、或所述诊疗室管理服务器为多个，所述接入服务器还包括：判断模块，用于在接收到的需要发送给所述配置管理服务器、所述消息服务器、或所述诊疗室管理服务器的数据包中，根据查询对象标识queryID判断该数据包所属的配置管理服务器、消息服务器、或诊疗室管理服务器；所述消息服务器、所述配置管理服务器以及所述诊疗室管理服务器之间相互独立。
2.根据权利要求1所述的系统，其特征在于，所述接入服务器包括：
第一接收模块，设置于接收来自于所述消息服务器、所述配置管理服务器、和/或所述诊疗室管理服务器的数据；
第一发送模块，与所述第一接收模块相连接，设置于将所述第一接收模块接收到的数据转发至客户端；
第二接收模块，设置于接收来自于所述客户端的数据；
第二发送模块，与所述第二接收模块相连接，设置于将所述第二接收模块接收到的数据转发至所述消息服务器、所述配置管理服务器、和/或所述诊疗室管理服务器。
3.根据权利要求1所述的系统，其特征在于，还包括：一个或多个新业务服务器，均与所述接入服务器相连接，用于承载新增加的业务，其中，所述业务服务器、所述消息服务器、所述配置管理服务器以及所述诊疗室管理服务器之间各个服务器相互独立。
4.根据权利要求1所述的系统，其特征在于，还包括：
客户端，与所述接入服务器相连接；
网站服务器，分别与所述配置管理服务器和消息服务器相连接。
5.一种应用于权利要求1至4中任一项所述的诊疗服务器系统的通信方法，其特征在于，包括：
接入服务器基于传输控制协议TCP链接接收来自于客户端的第一数据包；
所述接入服务器根据所述第一数据包中的包类型字节判断所述第一数据包为发送至配置管理服务器的数据包；
所述接入服务器根据所述第一数据包中的查询对象标识queryID判断该数据包所属的配置管理服务器；
所述接入服务器将所述第一数据包的头部去掉，套上数据后发送至所述所属的配置管理服务器。
6.根据权利要求5所述的方法，其特征在于，还包括：
所述接入服务器接收来自于配置管理服务器的第二数据包；
所述接入服务器根据所述第二数据包中的包类型字节判断所述第二数据包为发送至客户端的数据包；
所述接入服务器根据所述第二数据包的包头中用户标识userID判断客户端的接收端口；
所述接入服务器将所述第二数据包的包头去掉，发送至该接收端口。
7.一种应用于权利要求1至4中任一项所述的诊疗服务器系统的通信方法，其特征在于，包括：
接入服务器基于传输控制协议TCP链接接收来自于客户端的第三数据包；
所述接入服务器根据所述第三数据包中的包类型字节判断所述第三数据包为发送至诊疗室管理服务器的数据包；
所述接入服务器根据所述第三数据包中的查询对象标识queryID判断该数据包所属的所述诊疗室管理服务器；
所述接入服务器将所述第三数据包的头部去掉，套上数据后发送至所述所属的所述诊疗室管理服务器。
8.根据权利要求7所述的方法，其特征在于，还包括：
所述接入服务器接收来自于诊疗室管理服务器的第四数据包；
所述接入服务器根据所述第四数据包中的包类型字节判断所述第四数据包为发送至客户端的数据包；
所述接入服务器根据所述第四数据包的包头中用户标识userID判断客户端的接收端口；
所述接入服务器将所述第四数据包的包头去掉，发送至该接收端口。
9.一种应用于权利要求1至4中任一项所述的诊疗服务器系统的通信方法，其特征在于，包括：
接入服务器基于传输控制协议TCP链接接收来自于客户端的第五数据包；
所述接入服务器根据所述第五数据包中的包类型字节判断所述第五数据包为发送至消息服务器的数据包；
所述接入服务器根据所述第五数据包中的查询对象标识queryID判断该数据包所属的消息服务器；
所述接入服务器将所述第五数据包的头部去掉，套上数据后发送至所述所属的消息服务器。
10.根据权利要求9所述的方法，其特征在于，还包括：
所述接入服务器接收来自于消息服务器的第六数据包；
所述接入服务器根据所述第六数据包中的包类型字节判断所述第六数据包为发送至客户端的数据包；
所述接入服务器根据所述第六数据包的包头中用户标识userID判断客户端的接收端口；
所述接入服务器将所述第六数据包的包头去掉，发送至该接收端口。
CN201610079434.4A 2015-10-22 2016-02-05 诊疗服务器系统及其通信方法 Active CN105763605B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2015106896506 2015-10-22
CN201510689650 2015-10-22

Publications (2)

Publication Number Publication Date
CN105763605A CN105763605A (zh) 2016-07-13
CN105763605B true CN105763605B (zh) 2019-09-13

Family

ID=56330605

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610079434.4A Active CN105763605B (zh) 2015-10-22 2016-02-05 诊疗服务器系统及其通信方法

Country Status (1)

Country Link
CN (1) CN105763605B (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101751511A (zh) * 2008-12-03 2010-06-23 杭州创业软件股份有限公司 新型数字化医疗信息软件门户集成系统
CN102111410A (zh) * 2011-01-13 2011-06-29 中国科学院软件研究所 一种基于代理的单点登录方法及系统
CN102316160A (zh) * 2011-06-14 2012-01-11 贵阳朗玛信息技术股份有限公司 网站系统及其通信方法
CN203504603U (zh) * 2012-10-30 2014-03-26 贵阳朗玛信息技术股份有限公司 移动互联网语音社区的服务器架构

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2003234202A1 (en) * 2002-04-23 2003-11-10 Edgile, Inc. System for managing and delivering digital services through computer networks
CN100463480C (zh) * 2002-08-29 2009-02-18 中兴通讯股份有限公司 一种呼叫流量控制方法
CN103634620A (zh) * 2013-11-07 2014-03-12 中兴通讯股份有限公司 一种iptv登录的方法、接入服务器及终端

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101751511A (zh) * 2008-12-03 2010-06-23 杭州创业软件股份有限公司 新型数字化医疗信息软件门户集成系统
CN102111410A (zh) * 2011-01-13 2011-06-29 中国科学院软件研究所 一种基于代理的单点登录方法及系统
CN102316160A (zh) * 2011-06-14 2012-01-11 贵阳朗玛信息技术股份有限公司 网站系统及其通信方法
CN203504603U (zh) * 2012-10-30 2014-03-26 贵阳朗玛信息技术股份有限公司 移动互联网语音社区的服务器架构

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
CAS单点登录系统在数字医院建设中的应用;刘林东，吴向前;《软件导刊》;20140615;第13卷(第6期);摘要、前言、第1-3节，图1-2 *

Also Published As

Publication number Publication date
CN105763605A (zh) 2016-07-13

Similar Documents

Publication Publication Date Title
CN104429029B (zh) 网络中通过中央控制器的基于延迟的业务速率控制
Zhang et al. BC-EdgeFL: A defensive transmission model based on blockchain-assisted reinforced federated learning in IIoT environment
CN106056211B (zh) 神经元计算单元、神经元计算模块及人工神经网络计算核
CN109561226A (zh) 一种api混合多租户路由方法、系统和api网关
Song et al. Networking systems of AI: On the convergence of computing and communications
CN105940377A (zh) 用于基于云的虚拟化编排器的方法、系统和计算机可读介质
CN105282191B (zh) 负载均衡系统、控制器和方法
CN107959663A (zh) 一种利用患者身份信息加密的互联网诊疗系统与方法
CN103297390A (zh) 服务器反向连接客户端的实现方法
CN107846365A (zh) 一种基于sdn的负载均衡实现系统及方法
CN108124007A (zh) 消息数据实时传输的方法与装置
CN103546290B (zh) 具有用户组的第三方认证系统或方法
CN109218278A (zh) 安全规则的动态实现
WO2018016678A1 (ko) Iot 기반으로 획득된 사용자 정보를 클라우드 환경에서 관리하는 시스템 및 방법
Sivakumar et al. Wireless sensor network to cyber physical systems: Addressing mobility challenges for energy efficient data aggregation using dynamic nodes
CN106850547A (zh) 一种基于http协议的数据还原方法及系统
CN104871499B (zh) 通信节点、控制装置以及控制信息条目的管理方法
CN110417905A (zh) 一种合约发布方法、装置、设备和联盟链系统
CN105530157B (zh) Afdx网络交换机多个虚拟链路共享信用的架构及方法
CN105763605B (zh) 诊疗服务器系统及其通信方法
CN106856456A (zh) 缓存集群服务的处理方法及系统
CN107948005A (zh) 物联网协议的更新方法及装置
CN104240048A (zh) 一种订单综合处理平台
CN104506304B (zh) 一种增强密码设备按需服务能力的适配控制系统及方法
CN104838624B (zh) 一种控制业务数据在虚拟网络中转发的方法、装置及系统

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
EE01 Entry into force of recordation of patent licensing contract

Application publication date: 20160713

Assignee: Guiyang Longma Video Technology Co.,Ltd.

Assignor: GUIYANG LONGMASTER INFORMATION & TECHNOLOGY Co.,Ltd.

Contract record no.: X2023980033354

Denomination of invention: Diagnosis and treatment server system and its communication method

Granted publication date: 20190913

License type: Common License

Record date: 20230308

EE01 Entry into force of recordation of patent licensing contract
EE01 Entry into force of recordation of patent licensing contract

Application publication date: 20160713

Assignee: GUIYANG SANJIU INTERNET MEDICAL Co.,Ltd.

Assignor: GUIYANG LONGMASTER INFORMATION & TECHNOLOGY Co.,Ltd.

Contract record no.: X2023980033909

Denomination of invention: Diagnosis and treatment server system and its communication method

Granted publication date: 20190913

License type: Common License

Record date: 20230324

EE01 Entry into force of recordation of patent licensing contract