如何解决 parent client 接受 enclave 返回的消息解码的问题

[kevingzhang]

我的建议还是使用 GeneralMsg
这个是现在的 GeneralMsg 的 Protobuf

message GeneralMsg{
  oneof msg {
    ResponseError error = 1;
    PeerApprovePinnerRequest PeerApproveRequest = 2;
    PeerApprovePinnerResponse PeerApproveResponse = 3;
    ApplyToBePinnerRequest ApplyPinnerRequest = 4;
    ApplyToBePinnerResponse ApplyPinnerResponse = 5;
    ApplyToExecuteTaskRequest ApplyToExecuteTaskRequest = 6;
    WinnerExecutorCert WinnerExecutorCert = 7;
    ErrandExecutionRequest ErrandExecutionRequest = 8;
    ErrandExecutionFailedResponse ErrandExecutionFailedResponse = 9;
    ErrandAdhocCodeCapCheckerRequest ErrandAdhocCodeCapCheckerRequest = 10;
    ErrandAdhocCodeCapCheckerResponse ErrandAdhocCodeCapCheckerResponse = 11;
    ErrandExecutionSucceededResponse ErrandExecutionSucceededResponse = 12;
    TaskKeyGenerationApplyRequst TaskKeyGenerationApplyRequst = 13;
    TaskExecutionRequest TaskExecutionRequest = 14;
    TaskExecutionResponse TaskExecutionResponse = 15;
    TaskPinnerKeySliceRequest TaskPinnerKeySliceRequest = 16;
    TaskPinnerKeySliceResponse TaskPinnerKeySliceResponse = 17;
    PeerApproveRaRequest PeerApproveRaRequest = 18;
    PeerApproveRaResponse PeerApproveRaResponse = 19;
    TaskSignWithKeySlicesRequst TaskSignWithKeySlicesRequst = 20;
    TaskSignWithKeySlicesResponse TaskSignWithKeySlicesResponse = 21;
    TaskSignGetPinnerKeySliceRequest TaskSignGetPinnerKeySliceRequest = 22;
    TaskSignGetPinnerKeySliceResponse TaskSignGetPinnerKeySliceResponse = 23;
    TaskCommitSignResultRequest TaskCommitSignResultRequest = 24;
    KeyGenerationCandidateRequest KeyGenerationCandidateRequest = 25;
    SignCandidateRequest SignCandidateRequest = 26;
  }
}```

我们可以增加一个顶层字段 uint32 ref_req
这个 ref_req可以为 0. 表示这个消息不是任何 response. 而是一个单纯的 send.
如果不为 0, 则为一个顺序增加的 seq. 每次发送出去都会 +1. 我这里不设计使用 random 的原因是避免频繁的 Nitro rand 调用, 减少字节数

这个 ref_req 表示是一个response 消息. 对方的发送者注册了这个 req. 所以返回的时候带上.

对于发送方而言, 发送的时候需要注册一下这个 req. 这样 VMH 就知道如果 ref_req 为这个数字的消息回来,应该给谁去处理. 
如果 ref_req 为 0, 则没有预定注册过的接受者. 应该是 VMH 自己打开看

除了这个 ref_req , 其余的处理方法和以前的 GeneralMsg 一样的. Protobuf 自动处理类型标识. 解码成为应该是数据类型.

这样的设计会不会增加代码量? 
 应该不会. 因为所有的处理只发生在 VMH的两端. 他们处理之后脱去外壳, 留下的就是 GeneralMsg, 或者在脱掉一层, 只有里面具体的已经反序列化好的消息了. 对于 VMH 的客户而言, 他们不关心底层的 ref_req 和 GeneralMsg 的细节

此前我们在 P2P 中已经大量使用 GeneralMsg. 这个似乎是使用统一的底层传输协议中的唯一方法. 除非我们可以找到更加简单智能的解决方案

对于我们现在的测试 client 而言. 发送出去的 ref 递增. 回来的时候就返还给对应注册了回调的 test unit. 从 testunit 的角度上, 发出一个Request, 回调一个 Response. 这样代码应该还是很好写的.

Wrap unwrap 如果觉得麻烦, 可以写一个 Utility. 你传入一个 type 和一个 msg, 这个utility 替你打包成为 GeneralMsg, 反之亦然.

[kevingzhang]

使用 seq而不是 rand 避免重合, 同时因为 Amazon nitro 限制单一 enclave, 所以所有的通讯都是一个发送者和一个接受者. 按照顺序递增也是安全的

[kevingzhang]

你现在发送的"init"也可以顺势就修改成为一个 GeneralMsg. 这样我此前提出的疑问也没有了.

对于不需要等待 response 的发送, 指定 req 为 0. 如果需要等待答复. 那么设定一个 timeout 和一个 req. 在发送端维护一个 map. 如果 timeout 之前答复了, 直接发给注册者. 如果没有返回, 从表中删除. 未来再返回也给出一个错误信息打印出来即可.

[kevingzhang]

由于 VMH 后面对应多个 services. 所以也许我们还需要增加一个字段, 就是投递对端的接受者 ID. 当然, 如果 req 不为 0 就不需要了, 因为注册了回调接受者. 对于 req 为 0 的这种, 的确是需要一个接受 ID, 标明是哪个 services 应该来处理. 类似的, 也可以是某个 actor 来处理. 这个 ID 可以使用 str 类型

[kevingzhang]

这个是我们现在处理 p2p的 listen 的方法

fn listen_p2p_message(from_peer_id: &str, msg: &BrokerMessage) -> HandlerResult<()> {
    trace!("errand actor got p2p message from {}, msg is {:?}", from_peer_id, msg);
    Ok(ipfs_p2p::listen_message(
        &from_peer_id.clone(),
        &msg,
        move |g_msg, from_peer_id, reply_to| match g_msg.msg.clone() {
            Some(crate::p2p_proto::general_msg::Msg::ErrandExecutionRequest(req)) => {
                errand_execution_request_handler(from_peer_id, req, reply_to)
            }
            Some(crate::p2p_proto::general_msg::Msg::ErrandExecutionSucceededResponse(res)) => {
                errand_execution_succeeded_response_handler(from_peer_id, res, reply_to)
            }
            Some(crate::p2p_proto::general_msg::Msg::ErrandExecutionFailedResponse(req)) => {
                errand_execution_failed_response_handler(from_peer_id, req, reply_to)
            }
            Some(crate::p2p_proto::general_msg::Msg::ErrandAdhocCodeCapCheckerRequest(req)) => {
                errand_adhoc_code_cap_checker_request_handler(from_peer_id, req, reply_to)
            }
            Some(crate::p2p_proto::general_msg::Msg::ErrandAdhocCodeCapCheckerResponse(res)) => {
                errand_adhoc_code_cap_checker_response_handler(from_peer_id, res, reply_to)
            }
            _ => {
                trace!("Errand actor unhandled p2p message type {:?}", &g_msg);
                Ok(response_reply_with_subject(
                    "",
                    &reply_to,
                    "Errand actor unknown message".as_bytes().to_vec(),
                )?)
            }
        },
    )?)
}

我认为可以借鉴到 vsock