Clarify inter-node communication (INC) model

[tiziano88]

Currently we use the term "gRPC" to also talk about communication between nodes within the same application, where no "remote" call is happening, and certainly not over the gRPC protocol.

I suggest we name the communication mechanism between nodes Inter-Node Communication (INC) (similar to Inter-Process Communication (IPC)).

Each Node usually has a single type of Message that it handles as input:

oak/sdk/rust/oak/src/lib.rs

Lines 461 to 468 in b814073

	/// Trait implemented by Oak Nodes that operate on commands.
	///
	/// It has a single method for handling commands, which are [`Decodable`](crate::io::Decodable)
	/// objects that are received via the single incoming channel handle which is passed in at Node
	/// creation time. The return value is only used for logging in case of failure.
	pub trait Node<T: crate::io::Decodable> {
	fn handle_command(&mut self, command: T) -> Result<(), crate::OakError>;
	}

After #1108 this message may be defined in a proto file and include strongly typed handles that the node expects to receive.

I will add more details later, but if anyone has any thoughts, please reply here.

cc @project-oak/core @wildarch

[jul-sh]

Good idea, and thanks for clarifying. I was a bit confused by whether nodes communicate with each other over gRPC.

[wildarch]

+1 for INC, if we mention the name in the docs and explain the distinction between INC and gRPC I think that should clear things up.

[tiziano88]

I wonder whether this means that basically all Nodes would just accept incoming messages of type GrpcInvocation (perhaps renamed to OakNodeInvocation or something else). Then they would decode the request to a more specific type as part of the Node logic (which may be autogenerated, as it currently is).

[tiziano88]

We would also need to generate corresponding client stubs to invoke a node from another node. (@wildarch I think you just proposed something along those lines in https://app.slack.com/client/TC007KHA8/CHE9E13C3/thread/CHE9E13C3-1593003638.448300 )

[tiziano88]

An alternative approach, which may avoid having to create stubs:

From a service definition, create strongly typed invocation messages. For instance:

oak/examples/hello_world/proto/hello_world.proto

Lines 31 to 37 in 5f44058

	// As seen in https://grpc.io/docs/guides/concepts/.
	service HelloWorld {
	rpc SayHello(HelloRequest) returns (HelloResponse);
	rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);
	rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);
	rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);
	}

may generate the following messages:

message SayHelloInvocation {
  oak.handle.Receiver request = 1 [ (oak.handle.message_type) = "HelloRequest" ];
  oak.handle.Sender response = 2 [ (oak.handle.message_type) = "HelloResponse" ];
}

message LotsOfRepliesInvocation {
  oak.handle.Receiver request = 1 [ (oak.handle.message_type) = "HelloRequest" ];
  oak.handle.Sender responses = 2 [ (oak.handle.message_type) = "HelloResponse" ];
}

...

message SayHelloInvocation {
  oneof {
    SayHelloInvocation say_hello = 1;
    LotsOfRepliesInvocation lots_of_replies = 2;
    ...
  }
}

In this model, there is no extra code to generate (though some additional code generation may make things even more ergonomic to use)

[tiziano88]

A downside of the message generation approach is that it relies on the order of the methods in the service definition (so reordering methods would be a breaking change in terms of the generated API for the Node).