There are some Apache projects you can consider for serialization or RPC: * https://avro.apache.org/ * https://dubbo.apache.org/ * https://thrift.apache.org/ * https://github.com/apache/incubator-brpc
Avro is fairly popular in big data spaces thanks to Kafka. Thrift has a more well defined RPC API and is more similar to protobuf than avro. I like Avro for its schemas which can help reduce message size a bit with common schemas. On Sat, 26 Oct 2019 at 19:12, Mingshen Sun <[email protected]> wrote: > > Yes, this topic is worth to consider. I have looked at the prost library. I > prefer the second solution. > > To make the discussion more clear, can you give us an example for the KMS > protocol? ( > https://github.com/mesalock-linux/mesatee/blob/master/mesatee_services/kms/proto/src/proto.rs) > Thanks. > > > On Sat, Oct 26, 2019 at 11:12 AM Yu Ding <[email protected]> wrote: > > > Hi folks, > > > > MesaTEE is supporting more and more services. In the current RPC design, we > > need several handcrafted Rust struct for each service message. It is not > > very scalable and will cause maintainability issues. We need a better RPC > > framework. > > > > Seems that protobuf-styled RPC is the best choice. We have the following > > choices for the software stack > > (1) rust-protobuf + grpc-rust + tokio > > (2) prost + tonic (or alternatives) + tokio > > > > (1) is more stable, but the Rust codes generated from proto files are too > > much big, which finally leads to a super large TCB and bad for TEEs. (2) > > benefits from prost for its tiny codebase but it's changing rapidly. I like > > (2) better because it's better for TEE from the security/safety > > perspective. > > > > Any ideas? > > > > Best, > > Yu > > -- Matt Sicker <[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
