RSF 分布式服务框架-传输协议层设计
为什么80%的码农都做不了架构师?>>>
这是接上一篇文章《RSF 分布式服务框架设计》之后的续作,主要是 Hasor-RSF 协议层的设计。
RSF 的协议层设计可以很复杂也可以很简单。复杂是指这一层可以嵌套多层协议栈,让 RSF 的交互数据可以跑在各种协议之上,例如:HTTP、RTMP、也可以跑在相对底层的协议例如:TCP、UDP。
RSF 在协议层的设计上需要保留可能将来嵌套其它协议的支持,但不要设计的过于复杂。因此 RSF 的协议层的实现应该被分为两层,如下:
位于底层的传输协议可以是 TCP、UDP、RTMP、HTTP、等等各类听过或者没听过的网络协议。对于这些传输协议的要求只有一个 -- 那就是可以传输 RSF 数据包。
在 RSF 初期完全可以忽略传输协议这一层的设计,只要将 RSF 数据包丢到网络上然后远程程序接收到即可。因为传输协议无外乎是相当于给 RSF 数据包套了一层马甲,而这层马甲在初期作用并不大,可以随着完善逐步丰富。
接下来就是最关键的部分RSF 数据包的格式了,RSF 数据包的大体格式是“定长包头 + 变长包体”这种形式。并且协议被设计成为无状态的。
RSF数据交互形式:
RSF交互协议采用(请求/响应)这种模式,客户端发送某种类型的RSF数据包,服务器响应这种类型的请求。不需要握手协议。同时也是无状态的。
RSF数据包格式:
请求
* RSF 1.0 Request 协议* --------------------------------------------------------bytes =13* byte[1] version RSF版本(0xC1 or 0x81)* byte[8] requestID 请求ID* byte[1] keepData 保留区* byte[3] contentLength 内容大小(max ~ 16MB)* --------------------------------------------------------bytes =10* byte[2] servicesName-(attr-index) 远程服务名* byte[2] servicesGroup-(attr-index) 远程服务分组* byte[2] servicesVersion-(attr-index) 远程服务版本* byte[2] servicesMethod-(attr-index) 远程服务方法名* byte[2] serializeType-(attr-index) 序列化策略* --------------------------------------------------------bytes =1 ~ 1021* byte[1] paramCount 参数总数* byte[4] ptype-0-(attr-index,attr-index) 参数类型1* byte[4] ptype-1-(attr-index,attr-index) 参数类型2* ...* --------------------------------------------------------bytes =1 ~ 1021* byte[1] optionCount 选项参数总数* byte[4] attr-0-(attr-index,attr-index) 选项参数1* byte[4] attr-1-(attr-index,attr-index) 选项参数2* ...* --------------------------------------------------------bytes =6 ~ 8192* byte[2] attrPool-size (Max = 2047) 池大小 0x07FF* byte[4] att-length 属性1大小* byte[4] att-length 属性2大小* ...* --------------------------------------------------------bytes =n* dataBody 数据内容* bytes[...]
响应
* RSF 1.0 Response 协议* --------------------------------------------------------bytes =13* byte[1] version RSF版本(0xC1 or 0x81)* byte[8] requestID 包含的请求ID* byte[1] keepData 保留区* byte[3] contentLength 内容大小(max ~ 16MB)* --------------------------------------------------------bytes =8* byte[2] status 响应状态* byte[2] serializeType-(attr-index) 序列化策略* byte[2] returnType-(attr-index) 返回类型* byte[2] returnData-(attr-index) 返回数据* --------------------------------------------------------bytes =1 ~ 1021* byte[1] optionCount 选项参数总数* byte[4] attr-0-(attr-index,attr-index) 选项参数1* byte[4] attr-1-(attr-index,attr-index) 选项参数2* ...* --------------------------------------------------------bytes =6 ~ 8192* byte[2] attrPool-size (Max = 2047) 池大小* byte[4] att-length 属性1大小* byte[4] att-length 属性2大小* ...* --------------------------------------------------------bytes =n* dataBody 数据内容* bytes[...]
上面列出了RSF在网络通信中所使用的数据包结构。
RSF数据包的主要结构是: “Head + ContentLength + Content”,这种包结构可以很方便的在底层网络框架上予以解析而且简单易懂。相比较淘宝 HSF2.0 的协议 RSF 的扩展性还算蛮强的。
Head 头:
RSF 的协议头采用 13 字节固定长度,其中包括了RSF在通信上的 5 个基本数据(RSF协议标记、协议版本、包类型、请求ID,数据包长度)。
第一个字节中RSF目前规定只有:“0xC1” 和 “0x81” 两个值。其中第1个二进制位用于表示RSF数据包,第2个二进制位用来表示请求或者响应,后面6个二进制位用来表示RSF协议版本。
所以有了:“0x80”可以用来检验是否为RSF数据包、“0xC0”用来表示RSF 请求数据包、“0x80”用来表示RSF响应数据包。所以依照这个规则“B2、F2、DA、FF”等值都是合法的,不过因为目前RSF协议版本只有1.0,所以只有 0xC1 和 0x81 是有效的。
接下来8个字节用来表示一个 long 值,这个值是请求ID。请求ID的作用是区分同一客户端在并发调用的情况下区分不同调用而设计的。
在接下来的 1 个字节为保留位。随后的 3 个字节表示一个 int 类型,这个值表示的是 RSF 头之后的 RSF 数据包总长度。这样就限制了RSF数据包大小最约 16MB。
Content 结构:
RSF 的包体中协议格式和传输的数据是分离设计的,这种设计会让协议本身的结构显得非常清晰。所有的属性值都会保存在属性池中,并且以其在属性池中位值加以替代。例如:
服务名为:“org.example.hello.MyService”的信息转换为二进制之后,将其放入属性池,然后用其在属性池中的位置加以表示(2字节 short 类型)。
此外对于键值这种结构的数据将会采用(4字节来表示),其中 key 由前两个字节表示,value用后两位字节表示。而这 4个字节恰好可以使用 int 类型来表示。
依照上面两个规则就形成了 RSF 请求响应的数据结构。
最后是属性池的设计,属性池的最大容量是 65535 条。依照现有的RSF协议规定根本无法达到这个量级,所以是十分安全的。
属性池中的数据都是 4 字节,用来表述内容大小。例如上面那个服务名其在属性池中的值是 27。
最后 dataBody 部分将会按照属性池中的顺序一次将属性内容排列下去。
假设提取位于属性池 3 号位置的属性属性值是 23,其前面两个属性大小均为 10 字节,那么 3号属性的实际位置就是 dataBody区域的 20~43 位置的数据。
属性池的 0 号属性:
属性池中 0 号属性是 RSF 协议中规定的固定属性,其属性值为 0。作为 0 长度的属性在 dataBody 区域是不会产生任何数据输出。
转载于:https://my.oschina.net/ta8210/blog/342091
RSF 分布式服务框架-传输协议层设计相关推荐
- RSF 分布式服务框架-服务端工作原理
为什么80%的码农都做不了架构师?>>> 这是接上一篇文章<RSF 分布式服务框架设计>之后的续作,主要是 Hasor-RSF 的请求响应工作原理以及设计思路. 非 ...
- RSF 分布式服务框架设计
为什么80%的码农都做不了架构师?>>> 是时候设计一个分布式服务框架了.我先将它定名为 Hasor-RSF,"RSF"为 Remote Service F ...
- RSF 分布式服务框架设计:线程模型
为什么80%的码农都做不了架构师?>>> RSF 的线程模型 使用了 RSF 框架之后系统一共会产生至少 7 条线程,有些功能的线程可能会产生多个.我们先来鸟瞰一下所有的线程和 ...
- 华为18级大牛倾情奉送:分布式服务框架和微服务设计原理实战文档,啃完发现涨薪如此简单
前言 分布式服务框架不仅仅包含核心的运行时类库,还包括服务划分原则.服务化最佳实践.服务治理.服务监控.服务开发框架等,它是一套完整的解决方案,用来协助应用做服务化改造,以及指导用户如何构建适合自己业 ...
- 阿里分布式服务框架Dubbo的架构总结
Dubbo是Alibaba开源的分布式服务框架,它最大的特点是按照分层的方式来架构,使用这种方式可以使各个层之间解耦合(或者最大限度地松耦合).从服务模型的角度来看,Dubbo采用的是一种非常简单的模 ...
- 分布式服务框架原理(一)设计和实现
分布式服务框架设计 分布式服务框架一般可以分为以下几个部分, (1)RPC基础层: 包括底层通信框架,如NIO框架.通信协议,序列化和反序列化协议, 以及在这几部分上的封装,屏蔽底层通信细节和序列化方 ...
- 分布式服务框架XXL-RPC
<分布式服务框架XXL-RPC> 一.简介 1.1 概述 XXL-RPC 是一个分布式服务框架,提供稳定高性能的RPC远程服务调用功能.拥有"高性能.分布式.注册中心. ...
- 读-李林峰-分布式服务框架和原理1-7
这哥们还写过一本netty的书,说实话这本书感觉不好,来过公司介绍过netty,讲的比较入门,因为当时在看netty源码,所以就不太感冒.后来学习公司服务框架的源码,想找本书系统了解下,又搜到这哥们, ...
- 分布式、集群、分布式服务框架
分布式: 1.将不同功能数据放到不能的机器上. 2.将同一数据放到不同的服务器上(数据副本),服务器之间通过网络互通.(涉及到数据的一致局性问题). 分布式系统的CAP理论: ● 一致性(C): ...
最新文章
- 查找文件命令find总结以及查找大文件
- c语言与python的区别
- 【6.1】python中的变量是什么
- Sql Server临时表中插入标示列
- 存根类 测试代码 java_嘲弄和存根–了解Mockito的测试双打
- django 返回ajax html,Django 前台通过json 取出后台数据
- 四、MyBatis 框架 Dao 动态代理
- MTCNN-tensorflow源码解析-gen_12net_data.py
- 服务器维修解锁,云服务器解锁
- Linux 文件类型!
- 达梦共享存储集群DMDSC-2节点部署手册
- 打破国外垄断,开发中国人自己的编程语言(1):编写解析表达式的计算器
- 多款iPhone遭遇中国禁售令!福建法院判决高通胜诉苹果
- 计算机一级照片错误怎么改,电脑上要怎么修改一寸照片大小
- CDR制作壮观的浩瀚宇宙星空实例教程
- 单片机LED与蜂鸣器原理与实践
- 适配新路由3(D2)的LEDE/OpenWrt固件
- apache、php安装
- Python——列表和元组
- 局域网内知道Mac地址查询对应IP
热门文章
- Android 节日短信送祝福(功能篇:2-短信历史记录Fragment的编写)
- How to change context root of a dynamic web project in Eclipse
- Android Unable to execute dex: java.nio.BufferOverflowException
- 病毒周报(100118至100124)
- 自定义的Spinner文字居中
- Android学习小Demo(9)一个To Do List的实现
- Android 软键盘盖住输入框的问题
- Struts2学习笔记(十九) 验证码
- 浅谈n个球和m个盒子之间的乱伦关系
- solidity语言开发智能合约