mirror of https://github.com/grpc/grpc.git
Jan Tattermusch
7 years ago
parent
05628719f1
commit
f389e5267a
13 changed files with 724 additions and 188 deletions
@ -0,0 +1,62 @@ |
|||||||
|
# gRPC Concepts Overview |
||||||
|
|
||||||
|
Remote Procedure Calls (RPCs) provide a useful abstraction for building |
||||||
|
distributed applications and services. The libraries in this repository |
||||||
|
provide a concrete implementation of the gRPC protocol, layered over HTTP/2. |
||||||
|
These libraries enable communication between clients and servers using any |
||||||
|
combination of the supported languages. |
||||||
|
|
||||||
|
|
||||||
|
## Interface |
||||||
|
|
||||||
|
Developers using gRPC start with the description of an RPC service (a collection |
||||||
|
of methods), and generate client and server side interfaces. The server implements |
||||||
|
the service interface, which can be remotely invoked by the client interface. |
||||||
|
|
||||||
|
By default, gRPC uses [Protocol Buffers](https://github.com/google/protobuf) as the |
||||||
|
Interface Definition Language (IDL) for describing both the service interface |
||||||
|
and the structure of the payload messages. It is possible to use other |
||||||
|
alternatives if desired. |
||||||
|
|
||||||
|
### Invoking & handling remote calls |
||||||
|
Starting from an interface definition in a .proto file, gRPC provides |
||||||
|
Protocol Compiler plugins that generate Client- and Server-side APIs. |
||||||
|
gRPC users call into these APIs on the Client side and implement |
||||||
|
the corresponding API on the server side. |
||||||
|
|
||||||
|
#### Synchronous vs. asynchronous |
||||||
|
Synchronous RPC calls, that block until a response arrives from the server, are |
||||||
|
the closest approximation to the abstraction of a procedure call that RPC |
||||||
|
aspires to. |
||||||
|
|
||||||
|
On the other hand, networks are inherently asynchronous and in many scenarios, |
||||||
|
it is desirable to have the ability to start RPCs without blocking the current |
||||||
|
thread. |
||||||
|
|
||||||
|
The gRPC programming surface in most languages comes in both synchronous and |
||||||
|
asynchronous flavors. |
||||||
|
|
||||||
|
|
||||||
|
## Streaming |
||||||
|
|
||||||
|
gRPC supports streaming semantics, where either the client or the server (or both) |
||||||
|
send a stream of messages on a single RPC call. The most general case is |
||||||
|
Bidirectional Streaming where a single gRPC call establishes a stream where both |
||||||
|
the client and the server can send a stream of messages to each other. The streamed |
||||||
|
messages are delivered in the order they were sent. |
||||||
|
|
||||||
|
|
||||||
|
# Protocol |
||||||
|
|
||||||
|
The [gRPC protocol](doc/PROTOCOL-HTTP2.md) specifies the abstract requirements for communication between |
||||||
|
clients and servers. A concrete embedding over HTTP/2 completes the picture by |
||||||
|
fleshing out the details of each of the required operations. |
||||||
|
|
||||||
|
## Abstract gRPC protocol |
||||||
|
A gRPC call comprises of a bidirectional stream of messages, initiated by the client. In the client-to-server direction, this stream begins with a mandatory `Call Header`, followed by optional `Initial-Metadata`, followed by zero or more `Payload Messages`. The server-to-client direction contains an optional `Initial-Metadata`, followed by zero or more `Payload Messages` terminated with a mandatory `Status` and optional `Status-Metadata` (a.k.a.,`Trailing-Metadata`). |
||||||
|
|
||||||
|
## Implementation over HTTP/2 |
||||||
|
The abstract protocol defined above is implemented over [HTTP/2](https://http2.github.io/). gRPC bidirectional streams are mapped to HTTP/2 streams. The contents of `Call Header` and `Initial Metadata` are sent as HTTP/2 headers and subject to HPACK compression. `Payload Messages` are serialized into a byte stream of length prefixed gRPC frames which are then fragmented into HTTP/2 frames at the sender and reassembled at the receiver. `Status` and `Trailing-Metadata` are sent as HTTP/2 trailing headers (a.k.a., trailers). |
||||||
|
|
||||||
|
## Flow Control |
||||||
|
gRPC uses the flow control mechanism in HTTP/2. This enables fine-grained control of memory used for buffering in-flight messages. |
||||||
@ -0,0 +1,488 @@ |
|||||||
|
# gRPC Basics: C++ |
||||||
|
|
||||||
|
This tutorial provides a basic C++ programmer's introduction to working with |
||||||
|
gRPC. By walking through this example you'll learn how to: |
||||||
|
|
||||||
|
- Define a service in a `.proto` file. |
||||||
|
- Generate server and client code using the protocol buffer compiler. |
||||||
|
- Use the C++ gRPC API to write a simple client and server for your service. |
||||||
|
|
||||||
|
It assumes that you are familiar with |
||||||
|
[protocol buffers](https://developers.google.com/protocol-buffers/docs/overview). |
||||||
|
Note that the example in this tutorial uses the proto3 version of the protocol |
||||||
|
buffers language, which is currently in alpha release: you can find out more in |
||||||
|
the [proto3 language guide](https://developers.google.com/protocol-buffers/docs/proto3) |
||||||
|
and see the [release notes](https://github.com/google/protobuf/releases) for the |
||||||
|
new version in the protocol buffers Github repository. |
||||||
|
|
||||||
|
## Why use gRPC? |
||||||
|
|
||||||
|
Our example is a simple route mapping application that lets clients get |
||||||
|
information about features on their route, create a summary of their route, and |
||||||
|
exchange route information such as traffic updates with the server and other |
||||||
|
clients. |
||||||
|
|
||||||
|
With gRPC we can define our service once in a `.proto` file and implement clients |
||||||
|
and servers in any of gRPC's supported languages, which in turn can be run in |
||||||
|
environments ranging from servers inside Google to your own tablet - all the |
||||||
|
complexity of communication between different languages and environments is |
||||||
|
handled for you by gRPC. We also get all the advantages of working with protocol |
||||||
|
buffers, including efficient serialization, a simple IDL, and easy interface |
||||||
|
updating. |
||||||
|
|
||||||
|
## Example code and setup |
||||||
|
|
||||||
|
The example code for our tutorial is in [examples/cpp/route_guide](route_guide). |
||||||
|
You also should have the relevant tools installed to generate the server and |
||||||
|
client interface code - if you don't already, follow the setup instructions in |
||||||
|
[BUILDING.md](../../BUILDING.md). |
||||||
|
|
||||||
|
## Defining the service |
||||||
|
|
||||||
|
Our first step is to define the gRPC *service* and the method *request* and |
||||||
|
*response* types using |
||||||
|
[protocol buffers](https://developers.google.com/protocol-buffers/docs/overview). |
||||||
|
You can see the complete `.proto` file in |
||||||
|
[`examples/protos/route_guide.proto`](../protos/route_guide.proto). |
||||||
|
|
||||||
|
To define a service, you specify a named `service` in your `.proto` file: |
||||||
|
|
||||||
|
```protobuf |
||||||
|
service RouteGuide { |
||||||
|
... |
||||||
|
} |
||||||
|
``` |
||||||
|
|
||||||
|
Then you define `rpc` methods inside your service definition, specifying their |
||||||
|
request and response types. gRPC lets you define four kinds of service method, |
||||||
|
all of which are used in the `RouteGuide` service: |
||||||
|
|
||||||
|
- A *simple RPC* where the client sends a request to the server using the stub |
||||||
|
and waits for a response to come back, just like a normal function call. |
||||||
|
|
||||||
|
```protobuf |
||||||
|
// Obtains the feature at a given position. |
||||||
|
rpc GetFeature(Point) returns (Feature) {} |
||||||
|
``` |
||||||
|
|
||||||
|
- A *server-side streaming RPC* where the client sends a request to the server |
||||||
|
and gets a stream to read a sequence of messages back. The client reads from |
||||||
|
the returned stream until there are no more messages. As you can see in our |
||||||
|
example, you specify a server-side streaming method by placing the `stream` |
||||||
|
keyword before the *response* type. |
||||||
|
|
||||||
|
```protobuf |
||||||
|
// Obtains the Features available within the given Rectangle. Results are |
||||||
|
// streamed rather than returned at once (e.g. in a response message with a |
||||||
|
// repeated field), as the rectangle may cover a large area and contain a |
||||||
|
// huge number of features. |
||||||
|
rpc ListFeatures(Rectangle) returns (stream Feature) {} |
||||||
|
``` |
||||||
|
|
||||||
|
- A *client-side streaming RPC* where the client writes a sequence of messages |
||||||
|
and sends them to the server, again using a provided stream. Once the client |
||||||
|
has finished writing the messages, it waits for the server to read them all |
||||||
|
and return its response. You specify a client-side streaming method by placing |
||||||
|
the `stream` keyword before the *request* type. |
||||||
|
|
||||||
|
```protobuf |
||||||
|
// Accepts a stream of Points on a route being traversed, returning a |
||||||
|
// RouteSummary when traversal is completed. |
||||||
|
rpc RecordRoute(stream Point) returns (RouteSummary) {} |
||||||
|
``` |
||||||
|
|
||||||
|
- A *bidirectional streaming RPC* where both sides send a sequence of messages |
||||||
|
using a read-write stream. The two streams operate independently, so clients |
||||||
|
and servers can read and write in whatever order they like: for example, the |
||||||
|
server could wait to receive all the client messages before writing its |
||||||
|
responses, or it could alternately read a message then write a message, or |
||||||
|
some other combination of reads and writes. The order of messages in each |
||||||
|
stream is preserved. You specify this type of method by placing the `stream` |
||||||
|
keyword before both the request and the response. |
||||||
|
|
||||||
|
```protobuf |
||||||
|
// Accepts a stream of RouteNotes sent while a route is being traversed, |
||||||
|
// while receiving other RouteNotes (e.g. from other users). |
||||||
|
rpc RouteChat(stream RouteNote) returns (stream RouteNote) {} |
||||||
|
``` |
||||||
|
|
||||||
|
Our `.proto` file also contains protocol buffer message type definitions for all |
||||||
|
the request and response types used in our service methods - for example, here's |
||||||
|
the `Point` message type: |
||||||
|
|
||||||
|
```protobuf |
||||||
|
// Points are represented as latitude-longitude pairs in the E7 representation |
||||||
|
// (degrees multiplied by 10**7 and rounded to the nearest integer). |
||||||
|
// Latitudes should be in the range +/- 90 degrees and longitude should be in |
||||||
|
// the range +/- 180 degrees (inclusive). |
||||||
|
message Point { |
||||||
|
int32 latitude = 1; |
||||||
|
int32 longitude = 2; |
||||||
|
} |
||||||
|
``` |
||||||
|
|
||||||
|
## Generating client and server code |
||||||
|
|
||||||
|
Next we need to generate the gRPC client and server interfaces from our `.proto` |
||||||
|
service definition. We do this using the protocol buffer compiler `protoc` with |
||||||
|
a special gRPC C++ plugin. |
||||||
|
|
||||||
|
For simplicity, we've provided a [Makefile](route_guide/Makefile) that runs |
||||||
|
`protoc` for you with the appropriate plugin, input, and output (if you want to |
||||||
|
run this yourself, make sure you've installed protoc and followed the gRPC code |
||||||
|
[installation instructions](../../BUILDING.md) first): |
||||||
|
|
||||||
|
```shell |
||||||
|
$ make route_guide.grpc.pb.cc route_guide.pb.cc |
||||||
|
``` |
||||||
|
|
||||||
|
which actually runs: |
||||||
|
|
||||||
|
```shell |
||||||
|
$ protoc -I ../../protos --grpc_out=. --plugin=protoc-gen-grpc=`which grpc_cpp_plugin` ../../protos/route_guide.proto |
||||||
|
$ protoc -I ../../protos --cpp_out=. ../../protos/route_guide.proto |
||||||
|
``` |
||||||
|
|
||||||
|
Running this command generates the following files in your current directory: |
||||||
|
- `route_guide.pb.h`, the header which declares your generated message classes |
||||||
|
- `route_guide.pb.cc`, which contains the implementation of your message classes |
||||||
|
- `route_guide.grpc.pb.h`, the header which declares your generated service |
||||||
|
classes |
||||||
|
- `route_guide.grpc.pb.cc`, which contains the implementation of your service |
||||||
|
classes |
||||||
|
|
||||||
|
These contain: |
||||||
|
- All the protocol buffer code to populate, serialize, and retrieve our request |
||||||
|
and response message types |
||||||
|
- A class called `RouteGuide` that contains |
||||||
|
- a remote interface type (or *stub*) for clients to call with the methods |
||||||
|
defined in the `RouteGuide` service. |
||||||
|
- two abstract interfaces for servers to implement, also with the methods |
||||||
|
defined in the `RouteGuide` service. |
||||||
|
|
||||||
|
|
||||||
|
<a name="server"></a> |
||||||
|
## Creating the server |
||||||
|
|
||||||
|
First let's look at how we create a `RouteGuide` server. If you're only |
||||||
|
interested in creating gRPC clients, you can skip this section and go straight |
||||||
|
to [Creating the client](#client) (though you might find it interesting |
||||||
|
anyway!). |
||||||
|
|
||||||
|
There are two parts to making our `RouteGuide` service do its job: |
||||||
|
- Implementing the service interface generated from our service definition: |
||||||
|
doing the actual "work" of our service. |
||||||
|
- Running a gRPC server to listen for requests from clients and return the |
||||||
|
service responses. |
||||||
|
|
||||||
|
You can find our example `RouteGuide` server in |
||||||
|
[route_guide/route_guide_server.cc](route_guide/route_guide_server.cc). Let's |
||||||
|
take a closer look at how it works. |
||||||
|
|
||||||
|
### Implementing RouteGuide |
||||||
|
|
||||||
|
As you can see, our server has a `RouteGuideImpl` class that implements the |
||||||
|
generated `RouteGuide::Service` interface: |
||||||
|
|
||||||
|
```cpp |
||||||
|
class RouteGuideImpl final : public RouteGuide::Service { |
||||||
|
... |
||||||
|
} |
||||||
|
``` |
||||||
|
In this case we're implementing the *synchronous* version of `RouteGuide`, which |
||||||
|
provides our default gRPC server behaviour. It's also possible to implement an |
||||||
|
asynchronous interface, `RouteGuide::AsyncService`, which allows you to further |
||||||
|
customize your server's threading behaviour, though we won't look at this in |
||||||
|
this tutorial. |
||||||
|
|
||||||
|
`RouteGuideImpl` implements all our service methods. Let's look at the simplest |
||||||
|
type first, `GetFeature`, which just gets a `Point` from the client and returns |
||||||
|
the corresponding feature information from its database in a `Feature`. |
||||||
|
|
||||||
|
```cpp |
||||||
|
Status GetFeature(ServerContext* context, const Point* point, |
||||||
|
Feature* feature) override { |
||||||
|
feature->set_name(GetFeatureName(*point, feature_list_)); |
||||||
|
feature->mutable_location()->CopyFrom(*point); |
||||||
|
return Status::OK; |
||||||
|
} |
||||||
|
``` |
||||||
|
|
||||||
|
The method is passed a context object for the RPC, the client's `Point` protocol |
||||||
|
buffer request, and a `Feature` protocol buffer to fill in with the response |
||||||
|
information. In the method we populate the `Feature` with the appropriate |
||||||
|
information, and then `return` with an `OK` status to tell gRPC that we've |
||||||
|
finished dealing with the RPC and that the `Feature` can be returned to the |
||||||
|
client. |
||||||
|
|
||||||
|
Now let's look at something a bit more complicated - a streaming RPC. |
||||||
|
`ListFeatures` is a server-side streaming RPC, so we need to send back multiple |
||||||
|
`Feature`s to our client. |
||||||
|
|
||||||
|
```cpp |
||||||
|
Status ListFeatures(ServerContext* context, const Rectangle* rectangle, |
||||||
|
ServerWriter<Feature>* writer) override { |
||||||
|
auto lo = rectangle->lo(); |
||||||
|
auto hi = rectangle->hi(); |
||||||
|
long left = std::min(lo.longitude(), hi.longitude()); |
||||||
|
long right = std::max(lo.longitude(), hi.longitude()); |
||||||
|
long top = std::max(lo.latitude(), hi.latitude()); |
||||||
|
long bottom = std::min(lo.latitude(), hi.latitude()); |
||||||
|
for (const Feature& f : feature_list_) { |
||||||
|
if (f.location().longitude() >= left && |
||||||
|
f.location().longitude() <= right && |
||||||
|
f.location().latitude() >= bottom && |
||||||
|
f.location().latitude() <= top) { |
||||||
|
writer->Write(f); |
||||||
|
} |
||||||
|
} |
||||||
|
return Status::OK; |
||||||
|
} |
||||||
|
``` |
||||||
|
|
||||||
|
As you can see, instead of getting simple request and response objects in our |
||||||
|
method parameters, this time we get a request object (the `Rectangle` in which |
||||||
|
our client wants to find `Feature`s) and a special `ServerWriter` object. In the |
||||||
|
method, we populate as many `Feature` objects as we need to return, writing them |
||||||
|
to the `ServerWriter` using its `Write()` method. Finally, as in our simple RPC, |
||||||
|
we `return Status::OK` to tell gRPC that we've finished writing responses. |
||||||
|
|
||||||
|
If you look at the client-side streaming method `RecordRoute` you'll see it's |
||||||
|
quite similar, except this time we get a `ServerReader` instead of a request |
||||||
|
object and a single response. We use the `ServerReader`s `Read()` method to |
||||||
|
repeatedly read in our client's requests to a request object (in this case a |
||||||
|
`Point`) until there are no more messages: the server needs to check the return |
||||||
|
value of `Read()` after each call. If `true`, the stream is still good and it |
||||||
|
can continue reading; if `false` the message stream has ended. |
||||||
|
|
||||||
|
```cpp |
||||||
|
while (stream->Read(&point)) { |
||||||
|
...//process client input |
||||||
|
} |
||||||
|
``` |
||||||
|
Finally, let's look at our bidirectional streaming RPC `RouteChat()`. |
||||||
|
|
||||||
|
```cpp |
||||||
|
Status RouteChat(ServerContext* context, |
||||||
|
ServerReaderWriter<RouteNote, RouteNote>* stream) override { |
||||||
|
std::vector<RouteNote> received_notes; |
||||||
|
RouteNote note; |
||||||
|
while (stream->Read(¬e)) { |
||||||
|
for (const RouteNote& n : received_notes) { |
||||||
|
if (n.location().latitude() == note.location().latitude() && |
||||||
|
n.location().longitude() == note.location().longitude()) { |
||||||
|
stream->Write(n); |
||||||
|
} |
||||||
|
} |
||||||
|
received_notes.push_back(note); |
||||||
|
} |
||||||
|
|
||||||
|
return Status::OK; |
||||||
|
} |
||||||
|
``` |
||||||
|
|
||||||
|
This time we get a `ServerReaderWriter` that can be used to read *and* write |
||||||
|
messages. The syntax for reading and writing here is exactly the same as for our |
||||||
|
client-streaming and server-streaming methods. Although each side will always |
||||||
|
get the other's messages in the order they were written, both the client and |
||||||
|
server can read and write in any order — the streams operate completely |
||||||
|
independently. |
||||||
|
|
||||||
|
### Starting the server |
||||||
|
|
||||||
|
Once we've implemented all our methods, we also need to start up a gRPC server |
||||||
|
so that clients can actually use our service. The following snippet shows how we |
||||||
|
do this for our `RouteGuide` service: |
||||||
|
|
||||||
|
```cpp |
||||||
|
void RunServer(const std::string& db_path) { |
||||||
|
std::string server_address("0.0.0.0:50051"); |
||||||
|
RouteGuideImpl service(db_path); |
||||||
|
|
||||||
|
ServerBuilder builder; |
||||||
|
builder.AddListeningPort(server_address, grpc::InsecureServerCredentials()); |
||||||
|
builder.RegisterService(&service); |
||||||
|
std::unique_ptr<Server> server(builder.BuildAndStart()); |
||||||
|
std::cout << "Server listening on " << server_address << std::endl; |
||||||
|
server->Wait(); |
||||||
|
} |
||||||
|
``` |
||||||
|
As you can see, we build and start our server using a `ServerBuilder`. To do this, we: |
||||||
|
|
||||||
|
1. Create an instance of our service implementation class `RouteGuideImpl`. |
||||||
|
1. Create an instance of the factory `ServerBuilder` class. |
||||||
|
1. Specify the address and port we want to use to listen for client requests |
||||||
|
using the builder's `AddListeningPort()` method. |
||||||
|
1. Register our service implementation with the builder. |
||||||
|
1. Call `BuildAndStart()` on the builder to create and start an RPC server for |
||||||
|
our service. |
||||||
|
1. Call `Wait()` on the server to do a blocking wait until process is killed or |
||||||
|
`Shutdown()` is called. |
||||||
|
|
||||||
|
<a name="client"></a> |
||||||
|
## Creating the client |
||||||
|
|
||||||
|
In this section, we'll look at creating a C++ client for our `RouteGuide` |
||||||
|
service. You can see our complete example client code in |
||||||
|
[route_guide/route_guide_client.cc](route_guide/route_guide_client.cc). |
||||||
|
|
||||||
|
### Creating a stub |
||||||
|
|
||||||
|
To call service methods, we first need to create a *stub*. |
||||||
|
|
||||||
|
First we need to create a gRPC *channel* for our stub, specifying the server |
||||||
|
address and port we want to connect to without SSL: |
||||||
|
|
||||||
|
```cpp |
||||||
|
grpc::CreateChannel("localhost:50051", grpc::InsecureChannelCredentials()); |
||||||
|
``` |
||||||
|
|
||||||
|
Now we can use the channel to create our stub using the `NewStub` method |
||||||
|
provided in the `RouteGuide` class we generated from our `.proto`. |
||||||
|
|
||||||
|
```cpp |
||||||
|
public: |
||||||
|
RouteGuideClient(std::shared_ptr<Channel> channel, const std::string& db) |
||||||
|
: stub_(RouteGuide::NewStub(channel)) { |
||||||
|
... |
||||||
|
} |
||||||
|
``` |
||||||
|
|
||||||
|
### Calling service methods |
||||||
|
|
||||||
|
Now let's look at how we call our service methods. Note that in this tutorial |
||||||
|
we're calling the *blocking/synchronous* versions of each method: this means |
||||||
|
that the RPC call waits for the server to respond, and will either return a |
||||||
|
response or raise an exception. |
||||||
|
|
||||||
|
#### Simple RPC |
||||||
|
|
||||||
|
Calling the simple RPC `GetFeature` is nearly as straightforward as calling a |
||||||
|
local method. |
||||||
|
|
||||||
|
```cpp |
||||||
|
Point point; |
||||||
|
Feature feature; |
||||||
|
point = MakePoint(409146138, -746188906); |
||||||
|
GetOneFeature(point, &feature); |
||||||
|
|
||||||
|
... |
||||||
|
|
||||||
|
bool GetOneFeature(const Point& point, Feature* feature) { |
||||||
|
ClientContext context; |
||||||
|
Status status = stub_->GetFeature(&context, point, feature); |
||||||
|
... |
||||||
|
} |
||||||
|
``` |
||||||
|
|
||||||
|
As you can see, we create and populate a request protocol buffer object (in our |
||||||
|
case `Point`), and create a response protocol buffer object for the server to |
||||||
|
fill in. We also create a `ClientContext` object for our call - you can |
||||||
|
optionally set RPC configuration values on this object, such as deadlines, |
||||||
|
though for now we'll use the default settings. Note that you cannot reuse this |
||||||
|
object between calls. Finally, we call the method on the stub, passing it the |
||||||
|
context, request, and response. If the method returns `OK`, then we can read the |
||||||
|
response information from the server from our response object. |
||||||
|
|
||||||
|
```cpp |
||||||
|
std::cout << "Found feature called " << feature->name() << " at " |
||||||
|
<< feature->location().latitude()/kCoordFactor_ << ", " |
||||||
|
<< feature->location().longitude()/kCoordFactor_ << std::endl; |
||||||
|
``` |
||||||
|
|
||||||
|
#### Streaming RPCs |
||||||
|
|
||||||
|
Now let's look at our streaming methods. If you've already read [Creating the |
||||||
|
server](#server) some of this may look very familiar - streaming RPCs are |
||||||
|
implemented in a similar way on both sides. Here's where we call the server-side |
||||||
|
streaming method `ListFeatures`, which returns a stream of geographical |
||||||
|
`Feature`s: |
||||||
|
|
||||||
|
```cpp |
||||||
|
std::unique_ptr<ClientReader<Feature> > reader( |
||||||
|
stub_->ListFeatures(&context, rect)); |
||||||
|
while (reader->Read(&feature)) { |
||||||
|
std::cout << "Found feature called " |
||||||
|
<< feature.name() << " at " |
||||||
|
<< feature.location().latitude()/kCoordFactor_ << ", " |
||||||
|
<< feature.location().longitude()/kCoordFactor_ << std::endl; |
||||||
|
} |
||||||
|
Status status = reader->Finish(); |
||||||
|
``` |
||||||
|
|
||||||
|
Instead of passing the method a context, request, and response, we pass it a |
||||||
|
context and request and get a `ClientReader` object back. The client can use the |
||||||
|
`ClientReader` to read the server's responses. We use the `ClientReader`s |
||||||
|
`Read()` method to repeatedly read in the server's responses to a response |
||||||
|
protocol buffer object (in this case a `Feature`) until there are no more |
||||||
|
messages: the client needs to check the return value of `Read()` after each |
||||||
|
call. If `true`, the stream is still good and it can continue reading; if |
||||||
|
`false` the message stream has ended. Finally, we call `Finish()` on the stream |
||||||
|
to complete the call and get our RPC status. |
||||||
|
|
||||||
|
The client-side streaming method `RecordRoute` is similar, except there we pass |
||||||
|
the method a context and response object and get back a `ClientWriter`. |
||||||
|
|
||||||
|
```cpp |
||||||
|
std::unique_ptr<ClientWriter<Point> > writer( |
||||||
|
stub_->RecordRoute(&context, &stats)); |
||||||
|
for (int i = 0; i < kPoints; i++) { |
||||||
|
const Feature& f = feature_list_[feature_distribution(generator)]; |
||||||
|
std::cout << "Visiting point " |
||||||
|
<< f.location().latitude()/kCoordFactor_ << ", " |
||||||
|
<< f.location().longitude()/kCoordFactor_ << std::endl; |
||||||
|
if (!writer->Write(f.location())) { |
||||||
|
// Broken stream. |
||||||
|
break; |
||||||
|
} |
||||||
|
std::this_thread::sleep_for(std::chrono::milliseconds( |
||||||
|
delay_distribution(generator))); |
||||||
|
} |
||||||
|
writer->WritesDone(); |
||||||
|
Status status = writer->Finish(); |
||||||
|
if (status.IsOk()) { |
||||||
|
std::cout << "Finished trip with " << stats.point_count() << " points\n" |
||||||
|
<< "Passed " << stats.feature_count() << " features\n" |
||||||
|
<< "Travelled " << stats.distance() << " meters\n" |
||||||
|
<< "It took " << stats.elapsed_time() << " seconds" |
||||||
|
<< std::endl; |
||||||
|
} else { |
||||||
|
std::cout << "RecordRoute rpc failed." << std::endl; |
||||||
|
} |
||||||
|
``` |
||||||
|
|
||||||
|
Once we've finished writing our client's requests to the stream using `Write()`, |
||||||
|
we need to call `WritesDone()` on the stream to let gRPC know that we've |
||||||
|
finished writing, then `Finish()` to complete the call and get our RPC status. |
||||||
|
If the status is `OK`, our response object that we initially passed to |
||||||
|
`RecordRoute()` will be populated with the server's response. |
||||||
|
|
||||||
|
Finally, let's look at our bidirectional streaming RPC `RouteChat()`. In this |
||||||
|
case, we just pass a context to the method and get back a `ClientReaderWriter`, |
||||||
|
which we can use to both write and read messages. |
||||||
|
|
||||||
|
```cpp |
||||||
|
std::shared_ptr<ClientReaderWriter<RouteNote, RouteNote> > stream( |
||||||
|
stub_->RouteChat(&context)); |
||||||
|
``` |
||||||
|
|
||||||
|
The syntax for reading and writing here is exactly the same as for our |
||||||
|
client-streaming and server-streaming methods. Although each side will always |
||||||
|
get the other's messages in the order they were written, both the client and |
||||||
|
server can read and write in any order — the streams operate completely |
||||||
|
independently. |
||||||
|
|
||||||
|
## Try it out! |
||||||
|
|
||||||
|
Build client and server: |
||||||
|
```shell |
||||||
|
$ make |
||||||
|
``` |
||||||
|
Run the server, which will listen on port 50051: |
||||||
|
```shell |
||||||
|
$ ./route_guide_server |
||||||
|
``` |
||||||
|
Run the client (in a different terminal): |
||||||
|
```shell |
||||||
|
$ ./route_guide_client |
||||||
|
``` |
||||||
@ -1,12 +0,0 @@ |
|||||||
Debug |
|
||||||
Debug-DLL |
|
||||||
Release |
|
||||||
Release-DLL |
|
||||||
*.suo |
|
||||||
*.user |
|
||||||
test_bin |
|
||||||
*.opensdf |
|
||||||
*.sdf |
|
||||||
third_party/*.user |
|
||||||
/packages |
|
||||||
/IntDir |
|
||||||
@ -1,11 +0,0 @@ |
|||||||
# Pre-generated MS Visual Studio project & solution files: DELETED |
|
||||||
|
|
||||||
**The pre-generated MS Visual Studio project & solution files are no longer available, please use cmake instead (it can generate Visual Studio projects for you).** |
|
||||||
|
|
||||||
**Pre-generated MS Visual Studio projects used to be the recommended way to build on Windows, but there were some limitations:** |
|
||||||
- **hard to build dependencies, expecially boringssl (deps usually support cmake quite well)** |
|
||||||
- **the nuget-based openssl & zlib dependencies are hard to maintain and update. We've received issues indicating that they are flawed.** |
|
||||||
- **.proto codegen is hard to support in Visual Studio directly (but we have a pretty decent support in cmake)** |
|
||||||
- **It's a LOT of generated files. We prefer not to have too much generated code in our github repo.** |
|
||||||
|
|
||||||
See [INSTALL.md](/INSTALL.md) for detailed instructions how to build using cmake on Windows. |
|
||||||
Loading…
Reference in new issue