CN112671937B - 一种聊天数据收发方法 - Google Patents
一种聊天数据收发方法 Download PDFInfo
- Publication number
- CN112671937B CN112671937B CN202110288024.1A CN202110288024A CN112671937B CN 112671937 B CN112671937 B CN 112671937B CN 202110288024 A CN202110288024 A CN 202110288024A CN 112671937 B CN112671937 B CN 112671937B
- Authority
- CN
- China
- Prior art keywords
- server
- chat data
- communication
- chat
- sending
- 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
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
一种聊天数据收发方法,涉及通信领域。方法应用于包括认证服务器、Web服务器集群、zookeeper服务器、通信服务器集群、消息队列服务器集群、注册中心的双通道聊天系统,方法包括聊天数据发送流程:Web服务器接收到发送端通过Restful接口发送的聊天数据时,将聊天数据打包并通过zookeeper服务器发送给空闲的通信服务器,该通信服务器解包向收件人信道发送聊天数据,还请求注册中心查找收件人连接的其他通信服务器,并经消息队列服务器转发聊天数据包给其他通信服务器,其他通信服务器解包并向收件人信道发送聊天数据;及聊天接收流程:当接收端及其登录的通信服务器信息在注册中心注册后,接收端等待登录的通信服务器发送的聊天数据。本发明收发模式安全且实时性好。
Description
技术领域
本发明涉及通信技术领域,尤其涉及一种聊天数据收发方法。
背景技术
现有聊天系统中,聊天推送服务部署在一台单独的服务器上,通过TCP服务对外提供端口和连接支持,所有需要聊天服务的客户端也通过TCP协议连接到该聊天服务器上,即采用TCP双工通信实现信息的发送与接收。由于TCP连接的设计,一旦建立连接,之后的通信无需再携带状态信息,可以直接发送。如有用户恶意大量发送垃圾数据,会给服务器带来极大压力。另外,连接数量受制于服务器的空闲端口,无法连接大量用户。
发明内容
本发明针对现有技术存在的问题,提出了一种基于双通道聊天系统实现的聊天数据收发方法,能连接大量用户,信息发送、接收实时性、安全性高。
本发明是通过以下技术方案得以实现的:
一种聊天数据收发方法,应用于包括认证服务器、Web服务器集群、zookeeper服务器 、通信服务器集群、消息队列服务器集群、注册中心的双通道聊天系统,方法包括:
聊天数据发送流程:
Web服务器接收到发送端通过Restful接口发送的聊天数据时,将聊天数据按照发件人信息、收件人信息、信息体的模式封装打包成聊天数据包,继而将聊天数据包通过zookeeper服务器发送给空闲的通信服务器;
接收到聊天数据包的通信服务器对聊天数据包解包,之后按照收件人信息查找在本通信服务器上的收件人信道并向收件人信道发送聊天数据;
接收到聊天数据包的通信服务器请求注册中心查找收件人连接的其他通信服务器,该通信服务器发送聊天数据包给对应的消息队列服务器,由该消息队列服务器转发聊天数据包给其他通信服务器;
其他通信服务器所对应的消息队列服务器监听到转发的聊天数据包后,其他通信服务器对各自接收到的聊天数据包解包,之后按照收件人信息查找其他通信服务器上的收件人信道并向收件人信道发送聊天数据;
聊天数据接收流程:
当接收端及其登录的通信服务器信息在注册中心注册后,接收端与登录的通信服务器建立收件人信道连接,接收端等待接收登录的通信服务器发送的聊天数据。
本发明将用户的信息发送与接收分开实现,发送端采用restful接口发布聊天数据,继而通过Web服务器将聊天数据包发送给通信服务器,接收端采用通信服务器TCP服务接收聊天数据。在此方式下实现双通道模式,保证了发送与接收的实时性。本发明采用了分布式的通信服务器集群,可突破单服务器连接上限,能够实现单客户端发送,多客户端(即用户可登陆多个通信服务器)接收。
作为优选,所述聊天数据包括发送端加密的身份识别码、用户ID、包含发件人信息、收件人信息、信息体的聊天信息。
作为优选,所述聊天数据发送流程还包括,在发送端通过Restful接口发送聊天数据前,认证服务器对登陆的发送端进行加密运算,基于用户ID、发送端身份识别码的有效期、认证服务器名称加密获得发送端加密的身份识别码。
作为优选,所述聊天数据发送流程还包括,在对聊天数据进行封装打包前且在发送端加密的身份识别码生成之后,Web服务器通过认证服务器对聊天数据中的发送端加密的身份识别码进行解密,获得用户ID、发送端身份识别码的有效期、认证服务器名称;继而判断解密后用户ID是否与发送端的用户ID一致,判断发送端解密后的身份识别码的有效期是否与发送端的身份识别码有效期 一致,判断解密后的认证服务器名称是否与发送端登陆的认证服务器名称是否一致,三个条件均满足时审核通过。
作为优选,所述聊天数据发送流程还包括,当本通信服务器或其他服务器未在各自服务器内查找到收件人信道时,则将聊天数据保存在注册中心,等查找到收件人信道时,向收件人信道发送保存在注册中心的聊天数据。
作为优选,所述聊天数据发送流程还包括,当将聊天数据包通过zookeeper服务器发送给空闲的通信服务器之前,通信服务器启动,并在zookeeper服务器、注册中心、消息队列服务器进行注册。
作为优选,所述聊天数据接收流程还包括,在接收端及其登录的通信服务器信息在注册中心注册前,认证服务器对登陆的接收端进行加密运算,基于用户ID、接收端身份识别码的有效期、认证服务器名称加密获得接收端加密的身份识别码。
作为优选,所述聊天数据接收流程还包括,在接收端及其登录的通信服务器信息在注册中心注册前且在接收端加密的身份识别码生成后,登录的通信服务器对接收端进行身份审核。
作为优选,所述聊天数据接收流程还包括,当接收端登录通信服务器之前,通信服务器启动,并在zookeeper服务器、注册中心、消息队列服务器进行注册。
作为优选,所述发送端或所述接收端,位于移动终端或移动站点或web端。
本发明具有以下有益效果:
一种聊天数据收发方法:
1) 采用分布式的通信服务器集群,突破了单服务器连接的上限;
2) 采用不同的通信方式实现双通道聊天数据收发,即发送端发送聊天数据给Web服务器,接收端是通过通信服务器接收聊天数据,保证了发送与接收的实时性,又比单独用websocket连接同时收发的模式更安全,允许更多接收端连接;
3) 通过消息队列服务器转发聊天数据给其他通信服务器,接收端可在不同的通信服务器登录,实现单客户端发送,多客户端接收;
4) 本发明还加强了用户发送信息的审核,提高了发送信息的安全性。
附图说明
图1为实现本发明一种聊天数据收发方法的双通道聊天系统的系统架构图;
图2为本发明一种聊天数据收发方法中聊天数据发送流程的流程图;
图3为本发明一种聊天数据收发方法中聊天数据接收流程的流程图。
具体实施方式
以下是本发明的具体实施例并结合附图,对本发明的技术方案作进一步的描述,但本发明并不限于这些实施例。
图1示出了一种双通道聊天系统的系统架构图。系统包括认证服务器、Web服务器集群、zookeeper服务器、通信服务器集群、消息队列服务器集群、注册中心、网关。Web服务器集群由多个Web服务器构成。通信服务器集群为由多个通信服务器构成的分布式通信服务器集群。N个Web服务器集群与N个通信服务器成N:N映射关系,即任一Web服务器可以发送到任一通信服务器,任一通信服务器可以接收任一Web服务器的连接。消息队列服务器集群由多个消息队列服务器构成。一个消息队列服务器对应一个通信服务器。
基于上述系统,本发明提出一种聊天数据收发方法,方法包括聊天数据发送流程和聊天数据接收流程。
如图2,所述聊天数据发送流程包括:
步骤S01,Web服务器接收到发送端通过Restful接口发送的聊天数据时,将聊天数据按照发件人信息、收件人信息、信息体的模式封装打包成聊天数据包,继而将聊天数据包通过zookeeper服务器发送给空闲的通信服务器;
步骤S02,接收到聊天数据包的通信服务器对聊天数据包解包,之后按照收件人信息查找在本通信服务器上的收件人信道并向收件人信道发送聊天数据;
步骤S03,接收到聊天数据包的通信服务器请求注册中心查找收件人连接的其他通信服务器,该通信服务器发送聊天数据包给对应的消息队列服务器,由该消息队列服务器转发聊天数据包给其他通信服务器;
步骤S04,其他通信服务器所对应的消息队列服务器监听到转发的聊天数据包后,其他通信服务器对各自接收到的聊天数据包解包,之后按照收件人信息查找其他通信服务器上的收件人信道并向收件人信道发送聊天数据。
所述聊天数据包括发送端加密的身份识别码、用户ID、包含发件人信息、收件人信息、信息体的聊天信息。加密的身份识别码与用户ID放在http的数据头header里面,聊天信息放在http的body里面,一同由发送端通过Restful接口发送给Web服务器。
所述加密的身份识别码是在发送端通过Restful接口发送聊天数据前生成。为此,所述聊天数据发送流程还包括,在发送端通过Restful接口发送聊天数据前,认证服务器对登陆的发送端进行加密运算,基于用户ID、发送端身份识别码的有效期、认证服务器名称加密获得发送端加密的身份识别码。具体地,将用户ID、本身份识别码的有效期时间,做类型转换,转换成字符串后与认证服务器的名称一起组装成一个待加密字符串。将待加密字符串转变成字节码数组后用认证服务器中的密钥进行AES加密,得到加密后字节码数组。将数组转换为16进制后,再转换为字符串得到加密的身份识别码。
所述聊天数据发送流程还包括,在对聊天数据进行封装打包前且在发送端加密的身份识别码生成之后,Web服务器对用户身份进行安全性核实,核实通过后进行后续的数据发送。具体核实流程包括:Web服务器通过由认证服务器对聊天数据中的发送端加密的身份识别码进行解密,获得用户ID、发送端身份识别码的有效期、认证服务器名称;继而判断解密后用户ID是否与发送端的用户ID一致(如比对http头重提供的用户ID与解密后的用户ID是否一致),判断发送端解密后的身份识别码的有效期是否与发送端的身份识别码有效期(发送端的身份识别码有效期预存在Web服务器或注册中心,当预存在注册中心时,Web服务器可从注册中心获取发送端的身份识别码有效期)一致,判断解密后的认证服务器名称是否与发送端登陆的认证服务器名称是否一致,三个条件均满足时审核通过。一旦有一个条件不满足,则审核不通过。
在步骤S01中,聊天数据的打包流程具体包括:通过与用户ID对应的聊天用户表与用户表(用户表包括用户ID)进行一一映射,获得唯一对应于用户ID的收件人、发件人。之后将聊天数据按照发件人信息、收件人信息、信息体的模式封装打包成聊天数据包。打包规则是按照发件人信息+分隔符+收件人信息+信息体组装成字符串后,进行对称加密,然后转换字节数组进行打包。
Web服务器收到信息后,会把信息通过zookeeper服务器传到其中一台通信服务器。zookeeper服务器会弹性分配已在注册中心、网管、zookeeper服务器注册好的通信服务器。当有多个通信服务器时,则zookeeper服务器发送聊天数据包给空闲的一个通信服务器。
在步骤S02中,聊天数据包解包过程为上述聊天数据包打包过程的逆过程。解包时先把字节数组转换成字符串,然后用密钥进行解密。再按照顺序解出发件人信息、收件人信息、信息体。
基于解包后获得的收件人信息,接收到聊天数据包的通信服务器需要查找其是否有收件人信道,当收件人已经登录当前通信服务器时,则收件人信道存在的,只需将聊天数据包发送到收件信道内。若收件人未登录当前通信服务器,则无法查找到收件人信道,此时聊天数据包不发送,丢弃或者保存在注册中心,当收件人登录当前通信服务器时,注册中心的保存的待发送聊天数据以历史数据形式发送给收件人信道。
在步骤S03中,接收到聊天数据包的通信服务器还请求注册中心查找收件人连接的其他通信服务器。也就是说,收件人是可以通过其他通信服务器登录后进行不同端信息接收。当查到有一个或两个或多个其他通信服务器(所有收件人连接的通信服务器)时,当前通信服务器发送与其对应的消息队列服务器,由该消息队列服务器转发聊天数据包给查找到的其他通信服务器。其中接收端的收件人可用Web、APP、移动站点H5等不同的客户端登录。同样,发送端的发件人也可用Web、APP、移动站点H5等不同的客户端登录。一个聊天数据包会被转发多次,次数基于收件人连接的通信服务器数量。
在步骤S04中,其他通信服务器所对应的消息队列服务器监听步骤S03中的消息队列服务器是否转发聊天数据包,当监听到转发的聊天数据包后,其他通信服务器对各自接收的聊天数据包解包。解包时先把字节数组转换成字符串,然后用密钥进行解密。再按照顺序解出发件人信息、收件人信息、信息体。
基于解包后获得的收件人信息,其他通信服务器需要查找各自服务器是否有收件人信道,当收件人已经登录通信服务器时,则收件人信道存在的,只需将聊天数据包发送到收件信道内。若收件人未登录通信服务器,则无法查找到收件人信道,此时聊天数据包不发送,丢弃或者保存在注册中心,当收件人登录通信服务器时,注册中心的保存的待发送聊天数据以历史数据形式发送给收件人信道。
所述聊天数据发送流程还包括,当将聊天数据包通过zookeeper服务器发送给空闲的通信服务器之前,通信服务器启动,并在zookeeper服务器、注册中心、消息队列服务器进行注册。一旦注册成功后,说明该通信服务器可用。这样,通信服务器才能接收到zookeeper服务器发送的信息。
在通信服务器上的注册,是将用户ID与收件人信道进行绑定。每一个注册地址都关联了一个信道,在通信服务器上的注册,注册了用户ID与信道的绑定关系。在注册中心,注册了用户与服务器的对应关系。在通信服务器上,用户ID与收件人信道的绑定关系是标识与集合,因此,允许一个收件人(一个用户ID)有多个连接(多个收件人信道),这样可实现多终端登录。具体地,通信服务器启动,通信服务器先向注册中心注册,之后通信服务器向zookeeper服务器进行服务注册;最后,通信服务器向与之对应的消息队列服务器进行注册监理连接,做好数据转发监听工作。另外,当收件人下线时,会同时撤销通信服务器与注册中心的注册信息。
所述聊天数据接收流程包括:当接收端及其登录的通信服务器信息在注册中心注册后,接收端与登录的通信服务器建立收件人信道连接,接收端等待接收登录的通信服务器发送的聊天数据。
所述聊天数据接收流程还包括,在接收端及其登录的通信服务器信息在注册中心注册前,认证服务器对登陆的接收端进行加密运算,基于用户ID、接收端身份识别码的有效期、认证服务器名称加密获得接收端加密的身份识别码。具体地,将用户ID、本身份识别码的有效期时间,做类型转换,转换成字符串后与认证服务器的名称一起组装成一个待加密字符串。将待加密字符串转变成字节码数组后用认证服务器中的密钥进行AES加密,得到加密后字节码数组。将数组转换为16进制后,再转换为字符串得到加密的身份识别码。
所述聊天数据接收流程还包括,在接收端及其登录的通信服务器信息在注册中心注册前且在接收端加密的身份识别码生成后,登录的通信服务器对接收端进行身份审核。例如,通信服务器对接收端合法性验证,如是否在正常IP地址登录,如验证是虚假用户还是真实用户。这样,可进一步提高信息安全性。或者,该聊天数据接收流程不在注册之前进行身份审核,而是登录后直接建立通信信道,等待即将发出的聊天数据。
所述聊天数据接收流程还包括,当接收端登录通信服务器之前,通信服务器启动,并在zookeeper服务器、注册中心、消息队列服务器进行注册。一旦注册成功后,说明该通信服务器可用。这样,通信服务器才能与接收端的收件人建立收件人信道。
图3示出了聊天数据接收的示例流程。首先,接收端的用户登录认证服务器,得到经过加密的身份识别码。接着,接收端的用户通过网管登录到最近的通信服务器。之后,通信服务器对用户进行身份核实,当身份核实通过后,将用户与本通信服务器信息注册到注册中心。最后,接收端的用户与通信服务器建立信道连接,用户等待通信服务器发送信息。
本发明双通道聊天系统的设计出发点,就是将一个用户,按照收发功能,划分为收件人和发件人两个身份。本发明分别用不同的服务器进行,收发处理,来达到设计目的。发件人,通过restful接口,将信息发送到web服务器,然后有web服务器进行收件人的地址路由。收件人,经过身份识别后,通过websocket直接连接到通信服务器,等待接收信息。例如,发件人发了一条信息,通过zookeeper,web服务器选择了通信服务器A来处理。那么A会先在本服务器发送信息。然后从注册中心获取其他注册有收件人的通信服务器,得到通信服务器信息后,通过消息队列转发到其他通信服务器,其他通信服务器再在自身服务器内部信道上发送信息。
本领域的技术人员应理解,上述描述及附图中所示的本发明的实施例只作为举例而并不限制本发明。本发明的目的已经完整有效地实现。本发明的功能及结构原理已在实施例中展示和说明,在没有背离所述原理下,本发明的实施方式可以有任何变形或修改。
Claims (10)
1.一种聊天数据收发方法,应用于包括认证服务器、Web服务器集群、zookeeper服务器、通信服务器集群、消息队列服务器集群、注册中心的双通道聊天系统,其特征在于,方法包括:
聊天数据发送流程:
Web服务器接收到发送端通过Restful接口发送的聊天数据时,将聊天数据按照发件人信息、收件人信息、信息体的模式封装打包成聊天数据包,继而将聊天数据包通过zookeeper服务器发送给空闲的通信服务器;
接收到聊天数据包的通信服务器对聊天数据包解包,之后按照收件人信息查找在本通信服务器上的收件人信道并向收件人信道发送聊天数据;
接收到聊天数据包的通信服务器请求注册中心查找收件人连接的其他通信服务器,该通信服务器发送聊天数据包给对应的消息队列服务器,由该消息队列服务器转发聊天数据包给其他通信服务器;
其他通信服务器所对应的消息队列服务器监听到转发的聊天数据包后,其他通信服务器对各自接收到的聊天数据包解包,之后按照收件人信息查找其他通信服务器上的收件人信道并向收件人信道发送聊天数据;
聊天数据接收流程:
当接收端及其登录的通信服务器信息在注册中心注册后,接收端与登录的通信服务器建立收件人信道连接,接收端等待接收登录的通信服务器发送的聊天数据。
2.根据权利要求1所述的一种聊天数据收发方法,其特征在于,所述聊天数据包括发送端加密的身份识别码、用户ID、包含发件人信息、收件人信息、信息体的聊天信息。
3.根据权利要求1所述的一种聊天数据收发方法,其特征在于,所述聊天数据发送流程还包括,在发送端通过Restful接口发送聊天数据前,认证服务器对登陆的发送端进行加密运算,基于用户ID、发送端身份识别码的有效期、认证服务器名称加密获得发送端加密的身份识别码。
4.根据权利要求2所述的一种聊天数据收发方法,其特征在于,所述聊天数据发送流程还包括,在对聊天数据进行封装打包前且在发送端加密的身份识别码生成之后,Web服务器通过认证服务器对聊天数据中的发送端加密的身份识别码进行解密,获得用户ID、发送端身份识别码的有效期、认证服务器名称;继而判断解密后用户ID是否与发送端的用户ID一致,判断发送端解密后的身份识别码的有效期是否与发送端的身份识别码有效期一致,判断解密后的认证服务器名称是否与发送端登陆的认证服务器名称是否一致,三个条件均满足时审核通过。
5.根据权利要求1所述的一种聊天数据收发方法,其特征在于,所述聊天数据发送流程还包括,当本通信服务器或其他通信服务器未在各自服务器内查找到收件人信道时,则将聊天数据保存在注册中心,等查找到收件人信道时,向收件人信道发送保存在注册中心的聊天数据。
6.根据权利要求1所述的一种聊天数据收发方法,其特征在于,所述聊天数据发送流程还包括,当将聊天数据包通过zookeeper服务器发送给空闲的通信服务器之前,通信服务器启动,并在zookeeper服务器、注册中心、消息队列服务器进行注册。
7.根据权利要求1所述的一种聊天数据收发方法,其特征在于,所述聊天数据接收流程还包括,在接收端及其登录的通信服务器信息在注册中心注册前,认证服务器对登陆的接收端进行加密运算,基于用户ID、接收端身份识别码的有效期、认证服务器名称加密获得接收端加密的身份识别码。
8.根据权利要求1所述的一种聊天数据收发方法,其特征在于,所述聊天数据接收流程还包括,在接收端及其登录的通信服务器信息在注册中心注册前且在接收端加密的身份识别码生成后,登录的通信服务器对接收端进行身份审核。
9.根据权利要求1所述的一种聊天数据收发方法,其特征在于,所述聊天数据接收流程还包括,当接收端登录通信服务器之前,通信服务器启动,并在zookeeper服务器、注册中心、消息队列服务器进行注册。
10.根据权利要求1所述的一种聊天数据收发方法,其特征在于,所述发送端或所述接收端,位于移动终端或移动站点或web端。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110288024.1A CN112671937B (zh) | 2021-03-18 | 2021-03-18 | 一种聊天数据收发方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110288024.1A CN112671937B (zh) | 2021-03-18 | 2021-03-18 | 一种聊天数据收发方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112671937A CN112671937A (zh) | 2021-04-16 |
CN112671937B true CN112671937B (zh) | 2021-06-01 |
Family
ID=75399535
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110288024.1A Active CN112671937B (zh) | 2021-03-18 | 2021-03-18 | 一种聊天数据收发方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112671937B (zh) |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8315184B2 (en) * | 2009-12-17 | 2012-11-20 | Globaltel Media, Inc. | Computer to mobile two-way chat system and method |
CN102026203B (zh) * | 2010-12-17 | 2013-04-10 | 武汉大学 | 一种无线Mesh网中多SIP服务器布局方法 |
CN102202102B (zh) * | 2011-07-05 | 2014-08-13 | 施昊 | 基于云计算架构的网络服务聚合系统及其聚合方法 |
-
2021
- 2021-03-18 CN CN202110288024.1A patent/CN112671937B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN112671937A (zh) | 2021-04-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3198464B1 (en) | Application-aware multihoming for data traffic acceleration in data communications networks | |
EP1892887B1 (en) | Communication method between communication devices and communication apparatus | |
KR101263783B1 (ko) | 릴레이 서버를 이용한 데이터 전송 시스템 및 방법 | |
US20030023845A1 (en) | Method and apparatus for providing secure streaming data transmission facilites using unreliable protocols | |
EP0838930A2 (en) | Pseudo network adapter for frame capture, encapsulation and encryption | |
CN106656648B (zh) | 基于家庭网关的应用流量动态保护方法、系统及家庭网关 | |
Liu et al. | Softwarized IoT network immunity against eavesdropping with programmable data planes | |
CN115002023B (zh) | 一种链路聚合方法、链路聚合装置、电子设备及存储介质 | |
CN105657040B (zh) | 一种设备间内网通信的方法和系统 | |
CN108093041A (zh) | 单通道vdi代理服务系统及实现方法 | |
CN104184646A (zh) | Vpn网络数据交互方法和系统及其网络数据交互设备 | |
CN103379182A (zh) | 数据传输方法和客户端 | |
CN111194541A (zh) | 用于数据传输的装置和方法 | |
Liu et al. | P4NIS: Improving network immunity against eavesdropping with programmable data planes | |
CN112671937B (zh) | 一种聊天数据收发方法 | |
CN116015943B (zh) | 一种基于多级隧道混淆的隐私保护方法 | |
US20100030911A1 (en) | Data transfer acceleration system and associated methods | |
CN100428748C (zh) | 一种基于双重身份的多方通信方法 | |
CN105553986A (zh) | 一种基于udp的多寻址有限实时节点通信方法 | |
CN114679265A (zh) | 流量获取方法、装置、电子设备和存储介质 | |
US20230019877A1 (en) | Methods and systems for processing information streams | |
CN110351308B (zh) | 一种虚拟专用网络通信方法和虚拟专用网络设备 | |
CN113746807A (zh) | 一种区块链节点支持国密算法通信检测方法 | |
CN109462591B (zh) | 一种数据传输方法、接收方法、装置及系统 | |
JP2002026927A (ja) | カプセリング方法及び装置並びにプログラム記録媒体 |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |