|
4 | 4 |
|
5 | 5 | EosSdkRpc is an agent built on top of our EosSdk that uses gRPC as a mechanism to provide remote access to the SDK. |
6 | 6 |
|
7 | | -This agent is present in development versions of EOS, and is currently enabled via the "daemon" command set - starting in the 4.29 release a first-class CLI was created "management api eos-sdk-rpc" and is now the recommended configuration method. The gRPC interface that the agent supports closely matches the interface provided by EosSdk, and the intent is that the .proto interface can be publicly supported. As well as potentially allowing for remote access, using protobuf to specify the interface isolates customer code from the Linux ABI issues that come with building C++ applications on different compiler, libc, and kernel versions. |
| 7 | +This agent is present in development versions of EOS, and is currently enabled via the "daemon" command set - starting in the 4.29 release a first-class CLI was created `management api eos-sdk-rpc` and is now the recommended configuration method. The gRPC interface that the agent supports closely matches the interface provided by EosSdk, and the intent is that the .proto interface can be publicly supported. As well as potentially allowing for remote access, using protobuf to specify the interface isolates customer code from the Linux ABI issues that come with building C++ applications on different compiler, libc, and kernel versions. |
8 | 8 |
|
9 | | -The default listen point for the agent is localhost:9543 but this can be changed to allow external access. Only encrypted access is supported for EosSdkRpc agents configured via the “management api eos-sdk-rpc” CLI. An ACL should be used to limit the hosts that have access to the agent. |
| 9 | +The default listen point for the agent is `localhost:9543` but this can be changed to allow external access. Only encrypted access is supported for EosSdkRpc agents configured via the `management api eos-sdk-rpc` CLI. An ACL should be used to limit the hosts that have access to the agent. |
10 | 10 |
|
11 | 11 | The API mirroring is intended to be modular in the same fashion as the SDK itself. Each proto file mirrors one specific SDK module and the RPC definitions and messages also aim to be as close as possible to the original SDK API call, in an attempt to make the learning gap as small as possible. |
12 | 12 |
|
@@ -223,8 +223,8 @@ This will result in a directory proto being created under our root. Now we have |
223 | 223 |
|
224 | 224 | CMake has a good integration with Protobuf and already provides a convenient way to generate C++ files and headers. Unfortunately there is no official solution for gRPC yet. The file described below is a helper module to allow generation of gRPC C++ files with the same convenience as protobuf. |
225 | 225 |
|
226 | | -```cmake |
227 | | -## gRPC.cmake - a convenient gRPC proto file generator for CMake |
| 226 | +```cmake title="gRPC.cmake" |
| 227 | +## A convenient gRPC proto file generator for CMake |
228 | 228 |
|
229 | 229 | find_library( grpc_LIBRARY grpc REQUIRED ) |
230 | 230 | find_library( grpcpp_LIBRARY grpc++ REQUIRED ) |
@@ -262,8 +262,7 @@ endfunction() |
262 | 262 |
|
263 | 263 | Now we can start our own `CMakeLists.txt`: |
264 | 264 |
|
265 | | -```cmake |
266 | | -# CMakeLists.txt |
| 265 | +```cmake title="CMakeLists.txt" |
267 | 266 | cmake_minimum_required( VERSION 3.6 ) |
268 | 267 | project( eosrpcclient ) |
269 | 268 |
|
@@ -309,8 +308,7 @@ target_link_libraries( eosrpcclient |
309 | 308 |
|
310 | 309 | We can now add the client code (update the address on `CreateChannel`): |
311 | 310 |
|
312 | | -```c++ |
313 | | -// -- client.cc |
| 311 | +```c++ title="client.cc" |
314 | 312 | #include <grpc/grpc.h> |
315 | 313 | #include <grpcpp/grpcpp.h> |
316 | 314 | #include <grpcpp/client_context.h> |
@@ -374,9 +372,9 @@ Response to "show version": {"imageFormatVersion": "1.0", "uptime": 1506.9400000 |
374 | 372 |
|
375 | 373 | ### Expanding our previous example: creating and removing one EVPN route |
376 | 374 |
|
377 | | -Now, let's expand our example to use the SDK (ip_route) to add and remove a single static route. The example below builds on top of the previous. The differences are marked in bold. |
| 375 | +Now, let's expand our example to use the SDK (ip_route) to add and remove a single static route. The example below builds on top of the previous. |
378 | 376 |
|
379 | | -```cmake |
| 377 | +```cmake title="CMakeLists.txt" hl_lines="12 18 24-27 47" |
380 | 378 | cmake_minimum_required( VERSION 3.6 ) |
381 | 379 | project( eosrpcclient ) |
382 | 380 |
|
@@ -429,8 +427,7 @@ target_link_libraries( eosrpcclient |
429 | 427 |
|
430 | 428 | And the updated code, with some added functions: |
431 | 429 |
|
432 | | -```c++ |
433 | | -// -- client.cc |
| 430 | +```c++ title="client.cc" |
434 | 431 | #include <grpc/grpc.h> |
435 | 432 | #include <grpcpp/grpcpp.h> |
436 | 433 | #include <grpcpp/client_context.h> |
|
0 commit comments