Is this RPC protocol?

Viewed 80

What of the following two use cases are defined as RPC:

1

Client side serialize the code into binary format for example a python function gets pickled and put into the body of a message. The message is send to the server and then the server deserializes it and runs the function code. Takes the outcome and send the outcome back via network to the client. (code is defined client side and performed server side)

2

The client send a message with only the name text format of the method the server should perform. The server has the method defined on his side and runs the method. Afterwards the results got sent over the network back to the client. (code is defined server side and performed server side)

It seems that most people believe RPC is only defined and used as in the 2 use case. Another question: Grpc is only build and meant for the second use case isn't it?

1 Answers

RPC stands for "Remote Procedure Call". Both of your definitions are doing exactly this, doing remote call of some code with passing (serializing) arguments and returning result (serialized).

The only difference between both definitions is such that 1st definition sends serialized code to remote server, while 2nd uses code already located on server. But still 1st and 2nd are both kinds of RPCs, just differently implemented.

2nd definition is related to API ("Application Programming Interface"), because only 2nd definition has well-defined interface of pre-defined functions with fixed signatures. You "know" what functions are located in API and what params they need. Hence in 2nd case you just reference those remote functions by their names (or anyhow else), instead of sending code itself.

If to choose between two definitions then 2nd is more classical definition of RPC, it is closer to what usually people mean when speaking about RPC.

2nd case also is more secure - because 1st case allows Client to execute arbitrary unchecked/unreliable code on server, which can harm it. While 2nd case allows server to strictly decide what should be run with what types of params.

2nd case is also more informative, because API usually has lots of detailed documentation regarding each function awailable and its properties. In 1st case Client has to have deep understanding of Programming, because arbitrary code is not documented so well anymore as in 2nd API case.

But if you have 2nd case it doesn't mean that you can't have 1st case same time. For example inside 2nd-case API you can just implement function ResultTuple CallAnyCode(FunctionCode, ArgumentsTuple) - this kind of function may allow you to execute arbitrary code remotely. So you have well defined rich API with many function and inside this API there is one function to run arbitrary code (maybe with some higher authenticated rights of Administrator). This is also a common practice on some Servers. In this case 2nd definition will be including 1st definition inside it.

Regarding GRPC ("Google Remote Procedure Call") - it is just one possible implementation of RPC concept provided by Google and used widely inside all Google services as well.

GRPC has well defined strict interface of all functions (API). Every function has a name and format of input Protocol Buffer, basically all parameters described in structured binary form (similar to JSON but serialized in compact binary form). Resulting Protocol Buffer is also strictly described.

So GRPC actually corresponds to your 2nd definition. Because code is located on server and has strictly defined interface. And functions are referenced just by their names, without uploading any code to server.

But this doesn't mean that GRPC can't be used for executing arbitrary code. Still you can create GRPC function Result_ProtoBuf CallAnyCode(Code_plus_Arguments_ProtoBuf) through which you can pass arbitrary serialized code to server and execute it there, if you have enough permissions. In this case GRPC makes a function-wrapper that actually implements 1st definition also.

Related