CODEWITHSUNDEEP
protocol-buffers
gTcV
gTcV

Reputation: 2504

Remote object handles in Protocol Buffers?

Does Protocol Buffers support remote object handles? Say to support an API like the following:

service RemoteObjectsDemo {
    rpc AllocateRemoteObject() returns (RemoteObjectHandle);
    rpc UseRemoteObject(RemoteObjectHandle) returns (something);
    rpc FreeRemoteObject(RemoteObjectHandle) returns (Empty);
}

The point is that sometimes all you need is for some object to exist on the server, but there's not need to ever transfer that object across the wire.

Upvotes: 0

Views: 107

Answers (2)

aerobiotic
aerobiotic

Reputation: 396

If you were to return some database ID, then make another call and pass in the same ID to interact in more ways with the same data, that would work. You'd just lookup some state and continue where you left off. Generally, even if you load balance the application would be connecting to the same database.

You might be able to stay interactive with the same service by doing a stream of responses, which would look like this:

rpc DoSomething(SomeRequest) returns (stream ManyResponses);

Or do bi-directional streaming.

rpc FindMax(stream FindMaxRequest) returns (stream FindMaxResponse) {};

You'd need to come up with the rules of how many messages sent cause how many responses. Plus knowing when you'd want it all the end. Like in the above you can send values in one after the other, then whenever a new max is detected send back a response. When you ran out of values to send you'd do requestObserver.onComplete(). Then wait for all responses which would be indicated by and onComplete() event in the StreamObserver, perhaps with a latch to sync up response and sender.

Upvotes: 1

DazWilkin
DazWilkin

Reputation: 40426

Because gRPC and protocol buffers are language|runtime agnostic and because there's no universal concept of an object handle, protocol buffers does not expose process-specific object references.

Also, in many cases, it's not possible to assume that there's a single process implementing the RPC; load-balancers or other scale-out mechanisms will direct traffic to one of many backend processes.

That said, gRPC servers can track "things" that represent shared resources (often e.g. database|service connections) and there's no reason why this couldn't also be used to share objects.

You'd want to consider unique identifying the objects (hash|string, integer) and sharing this reference between clients and the server.

Bear in mind, that if the object reference is process-specific, you won't be able to scale-out the server as the per-process references won't work across processes.

Upvotes: 1

Related Questions