CN111683069A - 一种基于netty框架的自定义通信协议及服务方法 - Google Patents
一种基于netty框架的自定义通信协议及服务方法 Download PDFInfo
- Publication number
- CN111683069A CN111683069A CN202010467610.8A CN202010467610A CN111683069A CN 111683069 A CN111683069 A CN 111683069A CN 202010467610 A CN202010467610 A CN 202010467610A CN 111683069 A CN111683069 A CN 111683069A
- Authority
- CN
- China
- Prior art keywords
- service
- client
- thread
- byte stream
- length
- 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.)
- Granted
Links
Images
Classifications
-
- 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/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
-
- 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/08—Protocols for interworking; Protocol conversion
-
- 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/22—Parsing or analysis of headers
-
- 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/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Communication Control (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种基于netty框架的自定义通信协议及服务方法。本发明包括如下步骤:步骤1、客户端发起连接并和服务端建立加密的TCP传输通道;步骤2、服务端并发接收来自多个客户端的连接;步骤3、发送方用TLV编码器把业务信令解析成字节流;发送方包括客户端或服务端;步骤4、接收方用TLV解码器把接收到的字节流解析成业务信令;步骤5、服务端并发处理海量业务逻辑。本发明有益效果如下通过扩展netty框架提高***的数据监控能力。基于TCP层传输实现保证了数据流的准确性。自定义TLV协议的特性提高了数据传输效率,降低客户端和服务端***版本迭代的耦合性。提出了一种大规模并发网络请求处理的解决能力。
Description
技术领域
本发明涉及网络字节流传输、高并发业务处理等领域,提出了一种基于netty框架的自定义通信协议及服务***。
背景技术
在互联网在线应用服务中,一般产品中采用http传输协议和json数据协议较为普遍。这种实现模式的好处是开发实现门槛较低,数据简单直观不容易出错,容易测试,比较符合人一般直观思维,有利也有弊,它的局限性在于传输过程中数据冗余性较高,数据并发处理性能不佳,在一些要求低延迟和高并发的应用场景下使用这套技术组合则会显得非常吃力。如游戏、聊天和证券交易等高并发操作的网络应用场景,传输交互频繁,交互信令内容小,交互的每个信令对传输时效性要求很高对准确度要求很高。通过在netty网络框架基础上实现的这类通信功能,可以满足低延迟和高稳定性,做到事半功倍,能够很好满足上面这些特定要求。
发明内容
本发明的目的是针对现有技术实现上的不足和局限性,提供一种基于netty框架的自定义通信协议及服务***。
一种基于netty框架的自定义通信协议及服务***,包括协议规范定义,数据解码器,数据编码器,数据通道,io事件处理器,线程处理模型。netty是一种高效的网络通信框架和一种能灵活集成自定义数据协议编解码器的框架。本发明通过netty直观的bytebuf访问机制、内存回收机制、内存泄露追踪、支持开启TCPNODELAY等特性,本发明能够支持大规模高并发的请求响应,适合实时性稳定性要求高的网络游戏和证券交易等场景,本发明利用处理器链扩展了自定义数据通信协议,能有效压缩通信数据包,充分利用网络空间,通过减少通信带宽占用量,进一步提高了数据传输与接收效率。本发明用的自定义数据通信协议格式,相比通用的json,xml等格式,有更加快速高效的解析性能。
本发明实现了在TCP/IP层之上的应用层通信协议,可以用自定义协议负责编解码和粘包等处理,这是一种语言中立的数据传输格式,数据格式主体为Tag-Length-Value(以下概称TLV)的自定义协议,是传统Length-Value协议的变种,增加了Tag值,使网络传输的两端相对更加灵活。使用TLV协议格式传输后,编码器端可以自由增减不需要的字段而不会引起解码端的出错,降低服务版本升级迭代的耦合性。该自定义TLV协议规范的核心技术有2点,一是Value属性字段支持内嵌TLV格式,一个字段是复杂类型时候,一般就没办法用基本的TLV格式来表示,用循环内嵌的subTLV可以极大提升了该自定义协议的数据的表示能力。理论上支持一个subTLV里面可以再包含一个subTLV格式。二是Length属性字段长度支持动态扩展,一个字节为8位,在二进制中最大为:1111111111111111,等于十进制65535。在预设TLV协议中,我们定义,表示L值(即长度域值)的每个字节中,最高位不代表符号位也不代表数值,剩余15位用来表示L值;所以一个字节可表示的V区长度范围对应十进制为0~32767,对应十六进制的L值为0~7F。所以一个字节可以表示的L值最大为7F,当L值大于等于十六进制的80时,超出了两个字节可表示范围,则扩容到四个字节表示L值,80。首先判断第一长度域值本身所占的字节数是否大于预设字节数,如果第一长度域值本身所占的字节数大于预设字节数,则证明预设字节数不能完整的表示第一长度域值的本身大小;如果第一长度域值本身所占的字节数小于或等于预设字节数,则证明预设字节数可以完整的表示第一长度域值的本身大小。其中,在发明本实施例中,预设字节数为2。约定可以扩容到4字节来表示长度,一般在传输多媒体文件的场景中会使用到4字节长度表示。
一种基于netty框架的自定义通信协议及服务方法,包括如下步骤:
步骤1、客户端发起连接并和服务端建立加密的TCP传输通道;
步骤2、服务端并发接收来自多个客户端的连接;
步骤3、发送方(客户端或服务端)用TLV编码器把业务信令解析成字节流;
步骤4、接收方用TLV解码器把接收到的字节流解析成业务信令;
步骤5、服务端并发处理海量业务逻辑。
步骤详细的实现说明
步骤1实现如下:
1-1.建立连接,客户端主动向服务端指定的socket端口发送建立连接的请求,服务端根据当前资源占用情况,创建一个文件描述符,指派一个随机的端口和客户端建立TCP长连接。并维护一份全局的session信息,广播和通知等信令需要用到全局session;
1-2.获取动态密钥,为了消息传输的安全性和高效性,数据传输需既要加密又要求加解密速度快,用公私钥形式的非对称加密安全有保证,但是效率会有影响,故首次请求先使用预先内置在客户端的公钥加密业务信令,服务端收到业务信令后用对应的私钥解密,再生成一个动态密钥,再用私钥加密该动态密钥并返回给客户端,客户端收到响应后用公钥解密出动态密钥并缓存本次临时动态密钥,而服务端维护所有临时连接的动态密钥,一个动态密钥在一次tcp断开连接后就会失效;
1-3.加密通信,接下来的请求响应的数据加解密都是用对称加密算法,并在对称加密算法中使用上一步生成的动态密钥,这样分两步的做法即保证了密钥交互的安全性,又保证了加解密的时间效率;
根据步骤1-2和1-3所示,不同阶段切换使用不同加解密逻辑依赖到netty中pipeline处理链的动态替换的特性,可方便从RSA算法handler到AES算法handler的删除和添加。
步骤2所述的服务端并发接收来自多个客户端的连接实现如下:
2-1.创建一个ServerSocketChannel后指定一个服务监听端口,然后把ServerSocketChannel注册绑定到一个bossseletor中,bossselector只监听连接事件;
2-2.把bossseletor监听到每一个和客户端相关的socketChannel注册绑定到一组workselector中,workselector主要监听读事件;
2-3.在workselector监听到数据可读事件后会通知应用程序去读取保留在***内核的字节流;
2-4.应用程序会调用channelRead方法读取数据,每一个socketChannel在生命周期内都会绑定关联唯一一个workeventloop线程中,这样保证了事件按顺序处理,不需要额外同步开销就是线程安全的;
2-5.把耗时的业务处理器指定到专用业务线程池,使从io线程中独立分开。
步骤3实现如下:
3-1.发送方按照业务上的需要,把业务信令包装转化成一个个字节流数组,按照自定义数据协议格式:
首先对象属性按照事先定义的TAG值打包成一个个TLV,并把多个TLV字节流并成一个总的包体,加密包体内容,然后根据业务code和包体length计算打包一个24字节长度的固定包头,最后把包头和包体内容合并成要发送的字节流数组;
3-2.通过网络通道发送字节流,在业务上相互独立没有次序要求的数据包可以同时并行发送,客户端设置超时时间,在超过指定时间没有收到响应则放弃等待;
3-3.客户端并发收到多个响应信令可通过uuid来关联区分特定业务。
步骤4实现如下:
4-1.通道可读事件触发channelRead开始尝试读取24个字节数组作为协议包头,当可读取字节数组不够24,说明字节流还没有读取结束,也有可能是传输出现异常,这种情况直接返回不做任何处理,等待后面该通道新的可读事件;
4-2.当可读取字节数组等于或者超过24个字节,读取24个字节按协议格式依次解析出Version,Length,UUID,Type,Code;
4-3.根据步骤4-2中解析得到的Length数据,在计算出需要读取的包体大小,读取策略判断方式与步骤4-2相同,可读字节流不够则缓存包头对象并暂时退出等待下次可读事件,在可读字节流达到需要的包体大小长度时则执行读取整个包体到bytebuf数组中,用动态密钥解密该bytebuf字节流数组;
4-4.根据Code找到预先约定定义的业务对象来解析存储收到的包体数据;
所述的用自定义的TLV解析包体内容,这里接收方是基于netty框架实现的自定义协议解码器handler,使用TLV协议格式传输后,编码器端可以自由增加和删除不需要的字段而不会引起解码端的出错混乱,降低服务升级迭代的成本,降低耦合性。
步骤5实现如下:
5-1.通过BOSSGROUP线程组监听来自客户端的连接事件,创建客户端对应的socketChannel;
5-2.通过WORKGROUP线程组监听5-1步骤中创建的socketChannel通道的读事件,可轮询并发读取多个socketChannel中的数据到bytebuf中,解码bytebuf转换成POJO对象;
5-3.通过biz线程池来处理从5-2中得到的POJO对象,根据业务逻辑进行一些耗时的操作,比如读写数据库,文件访问,资源同步等待等耗时操作,独立业务线程池的使用避免了耗时业务线程影响到字节流读写线程和协议编解码线程;
5-4.通过5-3步骤处理后得出需要返回给客户端POJO对象,通过操作socketChannel的write方法将此POJO对象再交还给WORKGROUP线程处理,取出socketChannel绑定的线程并由该线程处理对象编码和字节流输出。每一个socketChannel在生命周期内都只会绑定关联唯一一个workeventloop线程中,这样保证了事件按顺序处理,不需要额外同步开销就能做到线程的安全运行。
本发明有益效果如下:
1.通过扩展框架提高***的监控能力。
2.基于TCP层实现可保证了传输的准确性。
3.自定义TLV协议的特性提高了数据传输效率,降低客户端和服务端***版本迭代的耦合性。
4.提出了一种大规模并发网络请求处理的解决能力。
附图说明
图1不同阶段数据加密传输示意图;
图2同步非阻塞IO多路复用时序图;
图3netty数据流向及处理器链路图;
图4TLV自定义协议格式规范图;
图5Netty数据流转及线程处理模型图。
具体实施方式
为了加深对本发明的理解,下面结合附图对本发明进一步说明,该实施仅用于解释本发明,并不对本发明的保护范围构成限定。
如图1-图5所示,本发明所述的是一种基于netty框架的自定义通信协议及服务***。
如图1所示,客户端和服务端建立TCP长连接后的,不同的阶段会使用不同的加密算法来传输数据,如图所示加密算法分对称加密和非对称加密。客户端首次向服务端请求得到本连接使用的动态密钥,首次请求交互使用非对称公私钥加密算法,客户端收到响应后用公钥解密出动态密钥并缓存临时动态密钥,而服务端维护所有连接的动态密钥,一个动态密钥在一次tcp断开连接后就会失效。在接下来的请求响应的数据加解密都是用对称加密算法,使用对应生成的动态密钥,这样分两步的做法即保证了密钥交互的安全性,又保证了加解密的时间效率,切换不同加密算法依赖到netty中pipeline处理器链的可动态删除和添加的特性。
如图2所示,在netty框架中,我们可以采用基于jdknio包实现的IO多路复用模型的事件驱动来支持多客户端并发读取数据,以buffer块形式把字节流数据从***内核拷贝到应用内存,不需要流式阻塞读取。
如图3所示,在netty中我们采用了一种合理规范的数据处理器链式结构,只有在约定的位置放置自定义通信协议处理器及业务处理器,整个数据流程才能正确运转起来。
如图4所示,这是一个自定义通信协议的完整格式规范、通过网络传输的一个完整包由固定长度的包头和不定长的包体组成,包头格式介绍:Version(协议版本),当前固定为1。Length(包头加包体总长度),3个字节表示长度[24,2^24-1],包头固定24字节,可计算出剩余包体长度length-24。UUID(信令唯一标识),一条完整的消息链接有一个独立唯一的id用来标示自己,异步化的业务场景需要唯一id来关联请求和回来的响应。Type(消息类型),可以表示请求(1),响应(2),通知(3)。Code(业务标识),一个code代表一个具体业务接口,根据code匹配预先定义的业务对象来解析接收到的包体数据。数据读取解析如下:
步骤1根据自定义协议中的约定格式,尝试读取24个字节数组作为协议包头header,当可读取字节不够24,说明字节流还没有读取结束,也有可能是消息传输出现异常,这种情况直接返回不做任何处理,等待后面该通道新的可读事件。当可读取字节数组等于或者超过24个字节,读取前24个字节作为包头的内容,该字节流按协议格式依次解析出Version,Length,UUID,Type,Code这5个值。
步骤2解析完header数据后根据上一步中解析得到的Length数据,再计算出需要读取的包体大小,读取策略判断同步骤1,可读字节流不够则缓存header对象并暂时退出等待下次可读事件。在可读字节流达到需要的包体大小长度时则读取整个包体到bytebuf数组中。
步骤3用动态密码解密还原该bytebuf字节流数组。
步骤4用自定义的nettyhandler解码器解析包体内容,按照TLV协议格式逐个解析,依据TLV的编码特性,编码器端可以增加和移除不需要的字段而不引起解码端的混乱,降低服务升级迭代的成本,可降低耦合性。支持数据类型有简单类型和复杂类型:简单类型指一般的整数,浮点型数据,及字符串;复杂类型包括2类,由简单类型组成的集合类型,如int[],list<double>,set<string>,map<string,string>,及自定义结构体类型,如struct{int,char,list}。
如图5所示,在采用netty的线程组处理模型后,基于异步事件的数据流处理能达到一种高并发处理信令的能力。为了达到这一目的,可通过BOSSGROUP线程组监听接收来自客户端的连接事件并创建对应的socketChannel通道,通过WORKGROUP线程组监听该socketChannel的读事件,轮询读取该通道中的数据到bytebuf对象中并解码该字节数组为POJO对象,根据不同的业务场景通过事先创建的业务线程组来处理一些耗时的操作,独立的业务线程组池的使用避免了耗时业务线程影响到字节流读写和协议编解码,最后业务线程计算得出需要返回给客户端POJO对象,通过操作socketChannel的write方法将此POJO对象再交还给WORKGROUP线程组处理。
以上内容和结构描述了本发明产品的基本原理、主要特征和本发明的优点,本行业的技术人员应该了解。上述实例和说明书中描述的只是说明本发明的原理,在不脱离本发明精神和范围的前提下,本发明还会有各种变化和改进,这些变化和改进都属于要求保护的本发明范围之内。本发明要求保护范围由所附的权利要求书及其等效物界定。
Claims (7)
1.一种基于netty框架的自定义通信协议及服务方法,其特征在于包括如下步骤:
步骤1、客户端发起连接并和服务端建立加密的TCP传输通道;
步骤2、服务端并发接收来自多个客户端的连接;
步骤3、发送方用TLV编码器把业务信令解析成字节流;发送方包括客户端或服务端;
步骤4、接收方用TLV解码器把接收到的字节流解析成业务信令;
步骤5、服务端并发处理海量业务逻辑。
2.根据权利要求1所述的一种基于netty框架的自定义通信协议及服务方法,其特征在于步骤1具体实现如下:
1-1.建立连接,客户端主动向服务端指定的socket端口发送建立连接的请求,服务端根据当前资源占用情况,创建一个文件描述符,指派一个随机的端口和客户端建立TCP长连接;并维护一份全局的session信息,广播和通知等信令需要用到全局session;
1-2.获取动态密钥,为了消息传输的安全性和高效性,数据传输需既要加密又要求加解密速度快,用公私钥形式的非对称加密安全有保证,但是效率会有影响,故首次请求先使用预先内置在客户端的公钥加密业务信令,服务端收到业务信令后用对应的私钥解密,再生成一个动态密钥,再用私钥加密该动态密钥并返回给客户端,客户端收到响应后用公钥解密出动态密钥并缓存本次临时动态密钥,而服务端维护所有临时连接的动态密钥,一个动态密钥在一次tcp断开连接后就会失效;
1-3.加密通信,接下来的请求响应的数据加解密都是用对称加密算法,并在对称加密算法中使用上一步生成的动态密钥,这样分两步的做法即保证了密钥交互的安全性,又保证了加解密的时间效率;
根据步骤1-2和1-3所示,不同阶段切换使用不同加解密逻辑依赖到netty中pipeline处理链的动态替换的特性,方便从RSA算法handler到AES算法handler的删除和添加。
3.根据权利要求1或2所述的一种基于netty框架的自定义通信协议及服务方法,其特征在于步骤2所述的服务端并发接收来自多个客户端的连接实现如下:
2-1.创建一个ServerSocketChannel后指定一个服务监听端口,然后把ServerSocketChannel注册绑定到一个boss seletor中,boss selector只监听连接事件;
2-2.把boss seletor监听到每一个和客户端相关的socketChannel注册绑定到一组work selector中,work selector主要监听读事件;
2-3.在work selector监听到数据可读事件后会通知应用程序去读取保留在***内核的字节流;
2-4.应用程序会调用channelRead方法读取数据,每一个socketChannel在生命周期内都会绑定关联唯一一个work eventloop线程中,这样保证了事件按顺序处理,不需要额外同步开销就是线程安全的;
2-5.把耗时的业务处理器指定到专用业务线程池,使从io线程中独立分开。
4.根据权利要求3所述的一种基于netty框架的自定义通信协议及服务方法,其特征在于步骤3实现如下:
3-1.发送方按照业务上的需要,把业务信令包装转化成一个个字节流数组,按照自定义数据协议格式:
首先对象属性按照事先定义的TAG值打包成一个个TLV,并把多个TLV字节流并成一个总的包体,加密包体内容,然后根据业务code和包体length计算打包一个24字节长度的固定包头,最后把包头和包体内容合并成要发送的字节流数组;
3-2.通过网络通道发送字节流,在业务上相互独立没有次序要求的数据包可以同时并行发送,客户端设置超时时间,在超过指定时间没有收到响应则放弃等待;
3-3.客户端并发收到多个响应信令可通过uuid来关联区分特定业务。
5.根据权利要求4所述的一种基于netty框架的自定义通信协议及服务方法,其特征在于步骤4实现如下:
4-1.通道可读事件触发channelRead开始尝试读取24个字节数组作为协议包头,当可读取字节数组不够24,说明字节流还没有读取结束,也有可能是传输出现异常,这种情况直接返回不做任何处理,等待后面该通道新的可读事件;
4-2.当可读取字节数组等于或者超过24个字节,读取24个字节按协议格式依次解析出Version,Length,UUID,Type,Code;
4-3.根据步骤4-2中解析得到的Length数据,在计算出需要读取的包体大小,读取策略判断方式与步骤4-2相同,可读字节流不够则缓存包头对象并暂时退出等待下次可读事件,在可读字节流达到需要的包体大小长度时则执行读取整个包体到bytebuf数组中,用动态密钥解密该bytebuf字节流数组;
4-4.根据Code找到预先约定定义的业务对象来解析存储收到的包体数据;
所述的用自定义的TLV解析包体内容,这里接收方是基于netty框架实现的自定义协议解码器handler,使用TLV协议格式传输后,编码器端可以自由增加和删除不需要的字段而不会引起解码端的出错混乱。
6.根据权利要求5所述的一种基于netty框架的自定义通信协议及服务方法,其特征在于步骤5实现如下:
5-1.通过BOSSGROUP线程组监听来自客户端的连接事件,创建客户端对应的socketChannel;
5-2.通过WORKGROUP线程组监听5-1步骤中创建的socketChannel通道的读事件,可轮询并发读取多个socketChannel中的数据到bytebuf中,解码bytebuf转换成POJO对象;
5-3.通过biz线程池来处理从5-2中得到的POJO对象,根据业务逻辑进行一些耗时的操作,比如读写数据库,文件访问,资源同步等待等耗时操作,独立业务线程池的使用避免了耗时业务线程影响到字节流读写线程和协议编解码线程;
5-4.通过5-3步骤处理后得出需要返回给客户端POJO对象,通过操作socketChannel的write方法将此POJO对象再交还给WORKGROUP线程处理,取出socketChannel绑定的线程并由该线程处理对象编码和字节流输出;每一个socketChannel在生命周期内都只会绑定关联唯一一个work eventloop线程中,这样保证了事件按顺序处理,不需要额外同步开销就能做到线程的安全运行。
7.根据权利要求6所述的一种基于netty框架的自定义通信协议及服务方法,其特征在于完整包由固定长度的包头和不定长的包体组成,包头格式介绍:Version(协议版本),当前固定为1;Length(包头加包体总长度),3个字节表示长度[24,2^24-1],包头固定24字节,可计算出剩余包体长度length-24;UUID(信令唯一标识),一条完整的消息链接有一个独立唯一的id用来标示自己,异步化的业务场景需要唯一id来关联请求和回来的响应;Type(消息类型),可以表示请求(1)、响应(2)、通知(3);Code(业务标识),一个code代表一个具体业务接口,根据code匹配预先定义的业务对象来解析接收到的包体数据。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010467610.8A CN111683069B (zh) | 2020-05-28 | 2020-05-28 | 一种基于netty框架的自定义通信协议及服务方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010467610.8A CN111683069B (zh) | 2020-05-28 | 2020-05-28 | 一种基于netty框架的自定义通信协议及服务方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111683069A true CN111683069A (zh) | 2020-09-18 |
CN111683069B CN111683069B (zh) | 2022-11-01 |
Family
ID=72453177
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010467610.8A Active CN111683069B (zh) | 2020-05-28 | 2020-05-28 | 一种基于netty框架的自定义通信协议及服务方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111683069B (zh) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112416408A (zh) * | 2020-12-08 | 2021-02-26 | 金卡智能集团股份有限公司 | 固件升级方法、装置、设备及计算机可读存储介质 |
CN112559146A (zh) * | 2020-12-07 | 2021-03-26 | 河南中烟工业有限责任公司 | 一种客户端与数据终端服务端的通讯方法 |
CN112637225A (zh) * | 2020-12-28 | 2021-04-09 | 厦门市美亚柏科信息股份有限公司 | 一种数据发送方法、接收方法、客户端及服务端 |
CN112995347A (zh) * | 2021-05-11 | 2021-06-18 | 北京沃丰时代数据科技有限公司 | 实现端对端实时数据展示的方法、装置、设备及存储介质 |
CN113553346A (zh) * | 2021-07-22 | 2021-10-26 | 中国电子科技集团公司第十五研究所 | 大规模实时数据流一体化处理、转发和存储方法及*** |
CN113905108A (zh) * | 2021-10-28 | 2022-01-07 | 珠海一微半导体股份有限公司 | 一种usb通讯的自定义协议分析装置、***及其运行方法 |
CN114422488A (zh) * | 2022-01-24 | 2022-04-29 | 北京理工大学重庆创新中心 | 一种基于netty框架的多线程消息处理方法 |
CN114553978A (zh) * | 2022-04-24 | 2022-05-27 | 深圳市城市交通规划设计研究中心股份有限公司 | 一种传感器报文数据处理方法、电子设备及存储介质 |
CN114640719A (zh) * | 2022-03-22 | 2022-06-17 | 康键信息技术(深圳)有限公司 | 基于Netty框架的数据处理方法、装置、设备及存储介质 |
CN114884927A (zh) * | 2021-10-22 | 2022-08-09 | 中国电力科学研究院有限公司 | 一种用于提高dl/t 698.45协议传输效率的方法和装置 |
CN114900568A (zh) * | 2022-05-05 | 2022-08-12 | 上海介方信息技术有限公司 | 针对分布式通信中间件实现可扩展传输协议的方法、终端 |
CN114995813A (zh) * | 2022-06-28 | 2022-09-02 | 上海中汇亿达金融信息技术有限公司 | 交易所api模块及相关的交易所应用平台 |
CN115174552A (zh) * | 2022-05-31 | 2022-10-11 | 华东计算技术研究所(中国电子科技集团公司第三十二研究所) | 基于web操作***的局域网通信和文件分享传输方法及*** |
CN115567621A (zh) * | 2022-10-13 | 2023-01-03 | 泉州砾鹰石科技有限公司 | 一种基于netty多协议单端口复用的方法 |
CN116095152A (zh) * | 2023-03-08 | 2023-05-09 | 杭州半云科技有限公司 | 一种基于多终端的多屏通信协同方法 |
CN116737349A (zh) * | 2023-08-16 | 2023-09-12 | ***紫金(江苏)创新研究院有限公司 | 流式数据处理方法、***及存储介质 |
CN117724869A (zh) * | 2023-12-19 | 2024-03-19 | 成都九天智信科技有限公司 | 一种基于web的自定义的***流程编辑器 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150201045A1 (en) * | 2014-01-13 | 2015-07-16 | Transcirrus | Automatic connection of nodes to a cloud cluster |
CN106534107A (zh) * | 2016-11-04 | 2017-03-22 | 北方工业大学 | 一种物联网消息服务*** |
-
2020
- 2020-05-28 CN CN202010467610.8A patent/CN111683069B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150201045A1 (en) * | 2014-01-13 | 2015-07-16 | Transcirrus | Automatic connection of nodes to a cloud cluster |
CN106534107A (zh) * | 2016-11-04 | 2017-03-22 | 北方工业大学 | 一种物联网消息服务*** |
Non-Patent Citations (2)
Title |
---|
JANNALS: "Netty案例(二)之耗时任务的处理", 《HTTPS://BLOG.CSDN.NET/USAGOOLE/ARTICLE/DETAILS/88025243》 * |
翟成彤: "基于长连接的分布式消息推送***设计与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》 * |
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112559146A (zh) * | 2020-12-07 | 2021-03-26 | 河南中烟工业有限责任公司 | 一种客户端与数据终端服务端的通讯方法 |
CN112559146B (zh) * | 2020-12-07 | 2023-04-18 | 河南中烟工业有限责任公司 | 一种客户端与数据终端服务端的通讯方法 |
CN112416408A (zh) * | 2020-12-08 | 2021-02-26 | 金卡智能集团股份有限公司 | 固件升级方法、装置、设备及计算机可读存储介质 |
CN112637225A (zh) * | 2020-12-28 | 2021-04-09 | 厦门市美亚柏科信息股份有限公司 | 一种数据发送方法、接收方法、客户端及服务端 |
CN112995347A (zh) * | 2021-05-11 | 2021-06-18 | 北京沃丰时代数据科技有限公司 | 实现端对端实时数据展示的方法、装置、设备及存储介质 |
CN112995347B (zh) * | 2021-05-11 | 2021-08-10 | 北京沃丰时代数据科技有限公司 | 实现端对端实时数据展示的方法、装置、设备及存储介质 |
CN113553346A (zh) * | 2021-07-22 | 2021-10-26 | 中国电子科技集团公司第十五研究所 | 大规模实时数据流一体化处理、转发和存储方法及*** |
CN114884927A (zh) * | 2021-10-22 | 2022-08-09 | 中国电力科学研究院有限公司 | 一种用于提高dl/t 698.45协议传输效率的方法和装置 |
CN113905108A (zh) * | 2021-10-28 | 2022-01-07 | 珠海一微半导体股份有限公司 | 一种usb通讯的自定义协议分析装置、***及其运行方法 |
CN113905108B (zh) * | 2021-10-28 | 2024-02-23 | 珠海一微半导体股份有限公司 | 一种usb通讯的自定义协议分析装置、***及其运行方法 |
CN114422488B (zh) * | 2022-01-24 | 2023-09-12 | 北京理工大学重庆创新中心 | 一种基于netty框架的多线程消息处理方法 |
CN114422488A (zh) * | 2022-01-24 | 2022-04-29 | 北京理工大学重庆创新中心 | 一种基于netty框架的多线程消息处理方法 |
CN114640719A (zh) * | 2022-03-22 | 2022-06-17 | 康键信息技术(深圳)有限公司 | 基于Netty框架的数据处理方法、装置、设备及存储介质 |
CN114553978A (zh) * | 2022-04-24 | 2022-05-27 | 深圳市城市交通规划设计研究中心股份有限公司 | 一种传感器报文数据处理方法、电子设备及存储介质 |
CN114900568B (zh) * | 2022-05-05 | 2024-04-02 | 上海介方信息技术有限公司 | 针对分布式通信中间件实现可扩展传输协议的方法、终端 |
CN114900568A (zh) * | 2022-05-05 | 2022-08-12 | 上海介方信息技术有限公司 | 针对分布式通信中间件实现可扩展传输协议的方法、终端 |
CN115174552A (zh) * | 2022-05-31 | 2022-10-11 | 华东计算技术研究所(中国电子科技集团公司第三十二研究所) | 基于web操作***的局域网通信和文件分享传输方法及*** |
CN115174552B (zh) * | 2022-05-31 | 2024-03-29 | 华东计算技术研究所(中国电子科技集团公司第三十二研究所) | 基于web操作***的局域网通信和文件传输方法及*** |
CN114995813B (zh) * | 2022-06-28 | 2023-12-19 | 上海中汇亿达金融信息技术有限公司 | 交易所api模块及相关的交易所应用平台 |
CN114995813A (zh) * | 2022-06-28 | 2022-09-02 | 上海中汇亿达金融信息技术有限公司 | 交易所api模块及相关的交易所应用平台 |
CN115567621A (zh) * | 2022-10-13 | 2023-01-03 | 泉州砾鹰石科技有限公司 | 一种基于netty多协议单端口复用的方法 |
CN116095152B (zh) * | 2023-03-08 | 2023-07-07 | 杭州半云科技有限公司 | 一种基于多终端的多屏通信协同方法 |
CN116095152A (zh) * | 2023-03-08 | 2023-05-09 | 杭州半云科技有限公司 | 一种基于多终端的多屏通信协同方法 |
CN116737349B (zh) * | 2023-08-16 | 2023-11-03 | ***紫金(江苏)创新研究院有限公司 | 流式数据处理方法、***及存储介质 |
CN116737349A (zh) * | 2023-08-16 | 2023-09-12 | ***紫金(江苏)创新研究院有限公司 | 流式数据处理方法、***及存储介质 |
CN117724869A (zh) * | 2023-12-19 | 2024-03-19 | 成都九天智信科技有限公司 | 一种基于web的自定义的***流程编辑器 |
Also Published As
Publication number | Publication date |
---|---|
CN111683069B (zh) | 2022-11-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111683069B (zh) | 一种基于netty框架的自定义通信协议及服务方法 | |
US10630654B2 (en) | Hardware-accelerated secure communication management | |
US7885412B2 (en) | Pre-generation of generic session keys for use in communicating within communications environments | |
US20100115041A1 (en) | Creating a message readable by a plurality of heterogeneous recipients | |
CN108390881A (zh) | 一种分布式高并发实时消息推送方法及*** | |
WO2019029320A1 (zh) | 一种配置管理方法、装置及设备 | |
WO2016082371A1 (zh) | 一种基于ssh协议的会话解析方法及*** | |
CN111565113B (zh) | 用于sdn控制器的灵活以太网网络拓扑抽象方法及*** | |
CN111966446B (zh) | 一种容器环境下rdma虚拟化方法 | |
KR20050004128A (ko) | Rtp 페이로드 포멧 | |
CN111859426B (zh) | 一种通用加密数据库连接器及其设置方法 | |
CN102231707A (zh) | 一种银行网点内数据报文可靠传输的方法和*** | |
CN1625179A (zh) | 按可定制的、基于标签协议中的引用发送 | |
CN109977137B (zh) | 一种数据查询方法和装置 | |
CN108040041B (zh) | 一种基于业务驱动的图像差异传输协议设计***及方法 | |
KR20040065246A (ko) | 네트워크를 통해 부가적인 정보를 송신하기 위한 시스템 | |
CN112953940A (zh) | 基于混合加密算法和关键属性过滤的安全发布订阅***及方法 | |
CN115412597B (zh) | 一种实时数据通信方法 | |
CN115499244A (zh) | 一种基于数据湖的流式数据安全传输和存储方法 | |
CN113839923B (zh) | 一种面向多节点的高性能处理方法 | |
CN101483653B (zh) | 网络设备向应用层提供应用层数据的方法、设备和*** | |
CN112291350A (zh) | 一种文件传输方法、***、设备以及介质 | |
CN113507469B (zh) | 一种基于ip网络的秘密通信*** | |
JP2996296B2 (ja) | メッセージ復号化装置及び有限状態機械生成装置 | |
CN109698966A (zh) | 一种登录流媒体以及数据交互加密的方法和装置 |
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 | ||
TA01 | Transfer of patent application right | ||
TA01 | Transfer of patent application right |
Effective date of registration: 20221019 Address after: 310006 room 106, No. 319, Shenjia Road, Xiacheng District, Hangzhou City, Zhejiang Province Applicant after: Hangzhou yinjieshi Biotechnology Co.,Ltd. Address before: 310013 7F, Guotou Building, No. 398 Shaoxing Road, Xiacheng District, Hangzhou, Zhejiang Applicant before: Hangzhou Ludu Information Technology Co.,Ltd. |