Hello,
given the fact that FSC provide both libp2p and websocket as a p2p communication protocol, I suggest to also support gRPC.
Rationale:
-
some organization needs to validate websocket and/or gRPC and/or libp2p protocol in their security blueprints. The most protocol FSC can support the better will be our integration position
-
HLF is already using gRPC and we do see the FSC p2p node communication at the same level as HLF peer <> HLF orderer <> HLF applications backends : these are server to server communications which have to comply with same OPS rules (deployment & security). That would be a great helper for OPS unification and simplifcation.
-
long term (and when all the firewall will be happy with these "new" protocols): both gRPC and websocket have their pros/cons and it seems to me that we could even choose one or another depending on the p2p use case. But here I guess that is an extra work to let the user define the underlying protocol with the view it implements...
Hello,
given the fact that FSC provide both libp2p and websocket as a p2p communication protocol, I suggest to also support gRPC.
Rationale:
some organization needs to validate websocket and/or gRPC and/or libp2p protocol in their security blueprints. The most protocol FSC can support the better will be our integration position
HLF is already using gRPC and we do see the FSC p2p node communication at the same level as HLF peer <> HLF orderer <> HLF applications backends : these are server to server communications which have to comply with same OPS rules (deployment & security). That would be a great helper for OPS unification and simplifcation.
long term (and when all the firewall will be happy with these "new" protocols): both gRPC and websocket have their pros/cons and it seems to me that we could even choose one or another depending on the p2p use case. But here I guess that is an extra work to let the user define the underlying protocol with the view it implements...