zookeeer client 通信协议

这里主要记录zookeeper client通信协议的.在官方的文档里没找到协议相关部分.这里是记录的协议是通过分析客户端代码得来的.

一.通信流程

客户端发起连接,发送握手包进行timeout协商,协商成功后会返回一个session id和timeoout值.随后就可以进行正常通信,通信过程中要在timeout范围内发送ping包.

zookeeper client和server之间的通信协议基本规则就是发送请求获取响应.并根据响应做不同的动作.

发送数据格式为:

消息长度+xid+request. xid每次请求必须是唯一的.消息长度和xid同为4字节,命令长度为4字节且必须为request的开始4字节.

命令是从1到11的数字表示,close的命令为-11.不同类型请求request有些差异.详细在第二部分.

特殊请求具有固定的xid:watch_xid固定为-1,ping_xid为-2,auth_xid固定为-4.普通请求一般从0开始每次请求累加一次xid.

响应数据为:

消息长度+header+response.消息长度为4字节,表明header+response的总长度.

header为xid,zxid,err对应长度为4,8,4.response根据请求类型不同具有差别.详细在第二部分

根据header里xid的区别分为watch,ping,auth,data这四种类型

根据这四种类型来区分返回消息是事件,还是认证,心跳和请求数据.client并以此作出不同响应.

二.各命令request

1.首先是握手connect,

  request:

      protocol version+zxid+timeout+session id+passwd len+passwd+read only.对应的字节长度为4,8,4,8,4,16,1

         取值除timeout外其他几个皆可为0,password可以为任意16个字符.read_only为0或1(是布尔值).

   握手包没有xid和命令

  response:

    protocol version,timeout,session_id,passwd len,passwd,read only.

   握手响应包没有header.

2.ping

  request:

type (ping包只有一个字段就是命令值是11,它完整的发送包是4字节长度,4字节xid,4字节命令.)

  response:

      res_len+header+res (ping响应包一般只拆到header即可通过xid确认)

3.create

request:

      type+path_len+path+data_len+data+acl_len+acl+flags

      type=1,4字节

      path_len是4字节,为path的长度,path为需要创建的路径,支持utf8

      data_len为4字节,为data的长度,data为节点的值,支持utf8

      acl_len,4字节.表明acl的长度.

      acl,详见acl描述部分.

      flags为4字节.

   response:

      data_len+data (无特殊情况即不再将res_len和header写出来,下面各请求也将如此.如没有将表明)

      data_len为4字节,data可以使用utf8

4.delete

   request:

      type+path_len+path+protocol version

      type=2

      path_len,path同create request

      protocol version 4字节,为-1则不进行版本检查.否则版本不同则删除失败

   response:

      只返回res_len+header.不返回res_data.

5.exists

   request:

      type+path_len+path+watcher

      type=3

      path_len,path同create request

      watcher为布尔值.判断是否有事件注册.为1或0. 1字节

   response:

      stat

      stat由8,8,8,8,4,4,4,8,4,4,8字节顺序组成.

6.getdata

   request:

       type+path_len+path+watcher

       type=4.其他字段同exists request

   response:

       data_len+data+stat

       data_len为data长度,4字节.

       stat同exists response

7.setdata

   request:

       type+path_len+path+data_len+data+protocol version

       type=4,

       path,data字段同create request

       protocol version 字段同delete request.-1为不考虑版本.

   response:

       stat

       同exists response

ACL:

   acl分两部分.一部分是标志.一部分是数据和id

   标志:

      all,read,write,create,delete,admin

      all=31,read=1,write=2,create=4,delete=8,admin=16 均为4字节

      若想表示其中某几项则使用对应项的值的和即可

   数据和id:

      数据和id都是字符串可以使用utf8,均为长度加字符.长度为4字节

   ACL完整标识:

      acl_标志+data_len+data+id_len+id

时间: 2025-01-06 02:03:13

zookeeer client 通信协议的相关文章

我的Modbus Slave/Client开发历程(Rtu/AscII/Tcp)

我的Modbus Slave/Client开发历程(Rtu/AscII/Tcp) 分类: [自动化]2007-07-19 10:04 34038人阅读 评论(38) 收藏 举报 vb嵌入式dostcp语言医疗 其实很早就想写写关于Modbus的开发历程,但牵扯项目较多,不同语言版本较多,头绪繁杂,一时不知从何写起.最近的医疗项目的通信部分,重新调整为Modbus协议,并且内容几乎涵盖了Modbus的方方面面(Rtu/Tcp,Slave/Client相关开发),所以更坚定了写Modbus信心,今天

MapReduce源代码分析之JobSubmitter(一)

JobSubmitter.顾名思义,它是MapReduce中作业提交者,而实际上JobSubmitter除了构造方法外.对外提供的唯一一个非private成员变量或方法就是submitJobInternal()方法,它是提交Job的内部方法,实现了提交Job的全部业务逻辑. 本文,我们将深入研究MapReduce中用于提交Job的组件JobSubmitter. 首先,我们先看下JobSubmitter的类成员变量.例如以下: // 文件系统FileSystem实例 private FileSys

X11 FRAMEBUFFER QT

之前对X11 FRAMEBUFFER理解的不够,现在总结一下Qt Embedded是挪威Trolletch公司的图形化界面开发工具Qt的嵌入式版本,它通过QtAPI与LinuxI/O以及Framebuffer直接交互,拥有较高的运行效率,而且整体采用面向对象编程,拥有良好地体系架构和编程模式. Qt/Embedded在原始Qt的基础上,做了许多出色的调整以适合嵌入式环境.同 Qt/X11相比,Qt/Embedded很节省内存,因为它不需要Xserver或是Xlib库,它在底层摒弃了Xlib,采用

Hadoop源码解析之 rpc通信 client到server通信

rpc是Hadoop分布式底层通信的基础,无论是client和namenode,namenode和datanode,以及yarn新框架之间的通信模式等等都是采用的rpc方式. 下面我们来概要分析一下Hadoop2的rpc. Hadoop通信模式主要是C/S方式,及客户端和服务端的模式. 客户端采用传统的socket通信方式向服务端发送信息,并等待服务端的返回. 服务端采用reactor的模式(Java nio)的方式来处理客户端的请求并给予响应. 一.客户端到服务端的通信 下面我们先分析客户端到

Hadoop 学习笔记五 ---Hadoop系统通信协议介绍

本文约定: DN: DataNode TT: TaskTracker NN: NameNode SNN: Secondry NameNode JT: JobTracker 本文介绍Hadoop各节点和Client之间通信协议. Hadoop的通信是建立在RPC的基础上,关于RPC的详解介绍大家可以参照 "hadoop rpc机制 && 将avro引入hadoop rpc机制初探" Hadoop中节点之间的通信是比较复杂的一个网络,若可以把它们之间的通信网络了解清楚,那么

了解saltstack的通信协议zeromq(一)

学了saltstack有一段时间了,说实话,对于一个python爱好者来说salt源代码真是一个宝藏啊.于是乎去看了源代码,发现所有问题都卡在了底层通信上,在看saltstack之前都不知道有一个这么好的zeromq通信协议.现在就来记录关于zeromq的学习笔记. zmq是什么:zmq是基于之前协议(tcp,ipc,inproc)开发的并发框架,采用异步IO非阻塞方式,多对多的通信模式,无需在意服务端和客户端的启动顺序.它包含四种通信模式:PAIR/PAIR,REP/REQ,PUB/SUB,P

Android开源库--Asynchronous Http Client异步http客户端

如果说我比别人看得更远些,那是因为我站在了巨人的肩上. github地址:https://github.com/loopj/android-async-http Api文档地址:http://loopj.com/android-async-http/doc/ http通信作为开发android最基本的模块,相信大家开发网络应用时都会需要用到. 在初学android的时候自己通过Apache的HttpClient类库实现了一个简单的http通信模块,线程安全,每次都要新建一个线程,通过Hander

redis client protocol 解析

在官网http://redis.io/topics/protocol有对redis通信协议有做说明. 基于下面的一些原因,我想解析redis client protocol: 1.足够了解通信协议,有助于做出更好的系统设计. 2.学习RESP的设计思想,不仅能扩展我的思维,也许将来能应用于我的代码中. 3.因为有些人想将redis client直接并入自己已有的系统中:包括我在内.这个将在我下一篇文章再做说明. 下面我翻译一下http://redis.io/topics/protocol一些我认

Hadoop - YARN 通信协议

一 简单介绍 RPC协议是连接各个组件的"大动脉",了解不同组件之间的RPC协议有助于我们更深入地学习YARN框架. 在YARN中.不论什么两个需相互通信的组件之间仅有一个RPC协议,而对于不论什么一个RPC协议,通信两方有一端是Client,还有一端为Server,且Client总是主动连接Server的,因此.YARN实际上採用的是拉式(pull-based)通信模型. 二  协议类型 YARN主要由下面几个RPC协议组成,各组件的通信协议(箭头指向的组件是RPC Server,而