N2N API的一些折腾（一）

N2N 2021/12/03 0

最近在折腾 MiniN2N 的小功能，实现查看当前虚拟小组（不是全部）下的在线列表

其实也就是利用N2N内置的API，文档见这里 （希望后续越来越完善）

同时也给出了基于python的示例，见这里

花点功夫研究了一下，同时也在MiniN2N上折腾了一番，跟我想的还是有点出入，于是就想着修改一下吧

所以先记录一下这API咋用（这应该是我接触的API里，最让人崩溃的一个）……

API

N2N很早以前就提供了edge/supernode的管理端口，基于UDP，之前也折腾过，发现好像也没什么卵用 :doge:

这次 3.0.0 发布，看到支持 json 日志输出，那就再折腾折腾呗

其实按我的理解，这个API说白了就是基于UDP的C/S通信简单实例

大概过程就是，客户端向管理端口发送一个包含API方法、验证信息等的包（文本），然后服务端返回相应的信息

于是研究了一下上面提到的示例，它的过程大约是这样：

python创建http服务，监听通过http get或post来的请求，分析pathinfo，拆分出API方法，通过socket提交给接口，服务端再返回信息

这样一分析，就一目了然了 :二哈:

学习

凑点字数，就汉化一下文档信息吧（只取关键信息，一些是我的个人理解和实践，路过的大佬请指教）

接口

任何方式向edge/supernode的管理端口发送报文（UDP，默认edge：5644 ，supernode：5645）

请求

一段明文文本，包含以下几个字段，每个字段用空格分隔 :二哈:

  • 消息类型
  • 选项（该字段是以冒号分隔的子字段集合，包含消息标签、消息标志、认证密钥（可选）3个子字段）
  • 方法
  • 附加参数

选项示例：666:1:bugxia、555:0:

请求示例：r 666:1:bugxia supernodes

请求详解

消息类型（Message Type）

r | w  r 表示read读方法（如：获取信息），w 表示write写方法（如：更新参数）

选项（Options）

消息标签（Message Tag）

0～999 每个请求都提供一个标签值，与此标签值关联的任何非错误回复都将包含此标签值

消息标志（Message Flags）

0 | 1 用于描述任何剩余的可选子字段，0 不存在其他子字段， 1 1个附加字段，包含身份验证密钥

认证密钥（Authentication Key 可选）

字符串 客户端提供的简单字符串密码，用于验证请求

方法（Method 官方文档里没有列举，全凭瞎猜）

其实方法在 sn_management.c 和 edge_management.c 里都能找到 :doge:

supernodes  暂时好像没什么卵用，原话是“Reserved for edge”，占位用的
edges  列出当前supernode下连接的全部edge（客户端、边缘节点）
communities  列出当前supernode下连接的全部community（虚拟小组）
reload_communities  重新加载通过 -c 参数提供的community.list和用户公钥
timestamps  列出一些supernode相关的时间戳（包含start_time\last_fwd\last_reg_super）
packetstats  列出supernode的流量统计数据（包含forward\broadcast\reg_super\errors）
verbose  日志等级，默认为3

返回值

每一个发送到管理端口的UDP报文都会返回一个JSON格式消息，形式如下：

  • 消息头
  • 消息正文
  • 消息尾
  • 错误消息

每一个返回信息中均包含两个固定键值，_tag 和 _type

_tag 包含来自请求的消息标签

_type 用于数据包内容类型标记，比如消息头对应该值为 begin 消息正文则为 row 消息尾则为 end 错误消息则为 error

通俗点说，也就是发送API请求后，根据begin标记做为入口来获取正文，然后end为止，遇到error就raise

折腾

最上面提到的python示例其实差不多已经涵盖了N2N API的全部用法，稍微花些时间，就能摸清N2N API的用法，还有一些不足

比如它是UDP协议的，当数据量足够大且请求频繁时，崩掉的可能必然会非常大 :doge:

然后还有一个就是，默认的管理端口是监听到本机127.0.0.1的，通过外部请求还得做一些修改

一群特立独行的大佬……后面有空我再水一篇吧

相关文章

评论（本站已开启评论回复邮件通知功能，请如实填写邮箱以便及时收到回复）