fix proto.message

message.proto

@@ -13,37 +13,38 @@ message SDLV6Info {
     bytes v6 = 2;
 }
 
-// 设备网络地址信息
+// 和super之间采用了quic协议通讯
-message SDLDevAddr {
+// 传输层采用: <<Len:16, Data/binary>>
-    uint32 network_id = 1;
+// 数据层采用: <<PacketId:32, PacketType:8, Payload/binary>>
-    bytes mac = 2;
-    uint32 net_addr = 3;
-    uint32 net_bit_len = 4;
-    string network_domain = 5;
-}
 
-// tcp通讯消息
+// quic 通讯消息
 message SDLEmpty {
 
 }
 
+// 这里修改成了扁平的结构, 否则有些字段不好找放的位置
 message SDLRegisterSuper {
     uint32 version = 1;
-    string installed_channel = 2;
+    string client_id = 2;
-    string client_id = 3;
+    // 网络地址信息已经有https请求分配了
-    SDLDevAddr dev_addr = 4;
+    // 注册的时候需要带上(network_id, mac, ip, mask_len, hostname)
-    string pub_key = 5;
+    uint32 network_id = 3;
-    string token = 6;
+    bytes mac = 4;
-    string network_code = 7;
+    uint32 ip = 5;
-    string hostname = 8;
+    uint32 mask_len = 6;
+    string hostname = 7;
+
+    string pub_key = 8;
+    // 客户端使用http协议请求后端，通过token或者账号密码登录时, 统一返回一个access_token;
+    // RegisterSuper的时候，验证凭证是否合法 (access_token)
+    string access_token = 9;
 }
 
+// 客户端的升级逻辑，在https的接口里面去完成
+// 部分逻辑会脱离quic去通讯，增加session_token校验
 message SDLRegisterSuperAck {
-    SDLDevAddr dev_addr = 1;
+    bytes aes_key = 1;
-    bytes aes_key = 2;
+    bytes session_token = 2;
-    uint32 upgrade_type = 3;
-    optional string upgrade_prompt = 4;
-    optional string upgrade_address = 5;
 }
 
 message SDLRegisterSuperNak {
@@ -63,6 +64,35 @@ message SDLPeerInfo {
     optional SDLV6Info v6_info = 3;
 }
 
+// ARP查询相关
+// 真实的arp请求是通过广播的形式获取到的，但是针对于macos这种tun的实现；是能够分析出arp请求包的；
+// 对于当前网络来说，服务端是知道mac对应的ip地址的，因此没有必要广播；直接通过服务器端返回
+message SDLArpRequest {
+    uint32 target_ip = 1;
+}
+
+message SDLArpResponse {
+    uint32 target_ip = 1;
+    bytes target_mac = 2;
+}
+
+// 权限请求查询相关
+message SDLPolicyRequest {
+    uint32 src_identity_id = 1;
+    uint32 dst_identity_id = 2;
+    uint32 version = 3;
+}
+
+// 基于quic通讯，rules部分已经没有了长度限制
+message SDLPolicyResponse {
+    uint32 src_identity_id = 1;
+    uint32 dst_identity_id = 2;
+    // 版本号，客户端需要比较版本号确定是否覆盖; 请求端自己去管理版本号，服务端只是原样回写
+    uint32 version = 3;
+    // 4+1+2 的稀疏序列化规则
+    bytes rules = 4;
+}
+
 // 事件定义
 
 message SDLNatChangedEvent {
@@ -82,30 +112,9 @@ message SDLNetworkShutdownEvent {
     string message = 1;
 }
 
-// 命令定义
-
-message SDLChangeNetworkCommand {
-    SDLDevAddr dev_addr = 1;
-    bytes aes_key = 2;
-}
-
-message SDLCommandAck {
-    // status = true, 表示成功；status = false 表示失败，message是失败原因描述 
-    bool status = 1;
-    optional string message = 2;
-}
-
-message SDLFlows {
-    // 服务器转发流量
-    uint32 forward_num = 1;
-    // p2p直接流量
-    uint32 p2p_num = 2;
-    // 接收的流量
-    uint32 inbound_num = 3;
-}
-
 // UDP通讯消息
 
+// client和stun之间的心跳包，客户端需要和super的udp之间的存活逻辑
 message SDLStunRequest {
     uint32 cookie = 1;
     string client_id = 2;
@@ -127,8 +136,31 @@ message SDLData {
     bool is_p2p = 4;
     uint32 ttl = 5;
     bytes data = 6;
+    bytes session_token = 7;
+    // 端通过https登录的时候，服务端会分配该端对应的权限标识
+    // 后续的请求过程中需要带上这个值，对端通过这个值要判断对数据包是否放行
+    uint32 identity_id = 8;
 }
 
+// 网络类型探测
+
+message SDLStunProbe {
+    uint32 cookie = 1;
+    uint32 attr = 2;
+    // 增加step是为了方便端上判断，收到的请求和响应之间的映射关系；服务器端原样返回
+    uint32 step = 3;
+}
+
+message SDLStunProbeReply {
+    uint32 cookie = 1;
+    // 增加step是为了方便端上判断，收到的请求和响应之间的映射关系；服务器端原样返回
+    uint32 step = 2;
+    uint32 port = 3;
+    uint32 ip = 4;
+}
+
+// Node-Node之间的握手逻辑, 是基于udp传输的
+
 message SDLRegister {
     uint32 network_id = 1;
     bytes src_mac = 2;
@@ -140,16 +172,3 @@ message SDLRegisterAck {
     bytes src_mac = 2;
     bytes dst_mac = 3;
 }
-
-// 网络类型探测
-
-message SDLStunProbe {
-    uint32 cookie = 1;
-    uint32 attr = 2;
-}
-
-message SDLStunProbeReply {
-    uint32 cookie = 1;
-    uint32 port = 2;
-    uint32 ip = 3;
-}