The C based gRPC (C++, Python, Ruby, Objective-C, PHP, C#)

gRPC - An RPC library and framework

gRPC is a modern, open source, high-performance remote procedure call (RPC) framework that can run anywhere. gRPC enables client and server applications to communicate transparently, and simplifies the building of connected systems.

Homepage: grpc.io
Mailing List: [email protected]om

Join the chat at https://gitter.im/grpc/grpc

To start using gRPC

To maximize usability, gRPC supports the standard method for adding dependencies to a user's chosen language (if there is one). In most languages, the gRPC runtime comes as a package available in a user's language package manager.

For instructions on how to use the language-specific gRPC runtime for a project, please refer to these documents

  • C++: follow the instructions under the src/cpp directory
  • C#: NuGet package Grpc
  • Dart: pub package grpc
  • Go: go get google.golang.org/grpc
  • Java: Use JARs from Maven Central Repository
  • Kotlin: Use JARs from Maven Central Repository
  • Node: npm install grpc
  • Objective-C: Add gRPC-ProtoRPC dependency to podspec
  • PHP: pecl install grpc
  • Python: pip install grpcio
  • Ruby: gem install grpc
  • WebJS: follow the grpc-web instructions

Per-language quickstart guides and tutorials can be found in the documentation section on the grpc.io website. Code examples are available in the examples directory.

Precompiled bleeding-edge package builds of gRPC master branch's HEAD are uploaded daily to packages.grpc.io.

To start developing gRPC

Contributions are welcome!

Please read How to contribute which will guide you through the entire workflow of how to build the source code, how to run the tests, and how to contribute changes to the gRPC codebase. The "How to contribute" document also contains info on how the contribution process works and contains best practices for creating contributions.

Troubleshooting

Sometimes things go wrong. Please check out the Troubleshooting guide if you are experiencing issues with gRPC.

Performance

See the Performance dashboard for performance numbers of master branch daily builds.

Concepts

See gRPC Concepts

About This Repository

This repository contains source code for gRPC libraries implemented in multiple languages written on top of a shared C core library src/core.

Libraries in different languages may be in various states of development. We are seeking contributions for all of these libraries:

Language Source
Shared C [core library] src/core
C++ src/cpp
Ruby src/ruby
Python src/python
PHP src/php
C# (core library based) src/csharp
Objective-C src/objective-c
Language Source repo
Java grpc-java
Kotlin grpc-kotlin
Go grpc-go
NodeJS grpc-node
WebJS grpc-web
Dart grpc-dart
.NET (pure C# impl.) grpc-dotnet
Owner
grpc
A high performance, open source, general-purpose RPC framework
grpc
Comments
  • LB policies request re-resolution without shutting down

    LB policies request re-resolution without shutting down

    Fixes #12731.

    I changed the code by intuition and I am still uncertain about lots of logic here. This initial commit can be compiled but increases the flakiness of at least grpclb_end2end test. And there is some asan issue I am looking at.


    This change is Reviewable

  • grpclb re-resolution

    grpclb re-resolution

    Currently, grpclb will hand off the re-resolution decision to its embedded RR policy. This PR lets grpclb to be in charge of its re-resolution. The connectivity of the balancers will also be taken into consideration so that grpclb will re-resolve only when both balancers and backends have been unreachable for some timeout.


    This change is Reviewable

  • Retry support

    Retry support

    ~~This is VERY preliminary code. It builds, and I don't think it breaks any existing functionality, but that's about all I can say for it at this point. There are "FIXME" comments all over the place that need to be addressed before this is done, and there may yet be some issues that I have not yet identified.~~

    ~~That having been said, I am sending it out at this point just to get a sanity check as to whether or not this approach is even moderately reasonable. Please look at the high-level structure and let me know if it seems reasonable. Also, please look at my use of atomics (and some of the FIXME comments about things that aren't currently atomics but may need to be) and let me know if it looks sane.~~

    ~~Also, note that I came up with what I think is a better alternative to the tee_byte_stream implementation in #10448. It will need some additional work later to support hedging, but I think the current approach is fine for retries. If it looks good to you, I can probably revert that other PR.~~

    ~~I would welcome any and all suggestions you may have on this. Thanks!~~

    This code is now ready for review!

    I would appreciate review from the following folks:

    • @ctiller: This code is really complex, and I am unwilling to trust it without careful review from you.
    • @dgquintas: Please review from the perspective of your general knowledge of the client channel code.
    • @ncteisen: Please review for compliance with the retry design.

    Some things to note:

    • This is a massive PR, so please let me know what I can do to make it easier to review. There is a large block comment in client_channel.cc describing the overall approach, but I'm sure it's not enough to understand everything. I would be happy to meet in person and do a code walk-through with some or all of you, or just answer any questions you may have.
    • This includes all configurable retry functionality except for the stats, which I will work on in a separate PR. (That will require working with the Census folks to figure out the right way to expose these stats.)
    • This does not include transparent retry support. That work depends on #11934 and will be added in a separate PR.
    • This does not include hedging support. I've kept that use-case in mind while writing this code, but more design discussions will need to occur to figure out how to implement it without impacting performance.
    • I have not yet verified that all tests pass, so there will no doubt be some fixes needed before this can be merged.
    • I will be interested to see what the performance impact of this is. It should hopefully be not very much, since all of the synchronization overhead is taken care of by the call combiner code, which was already merged. There is some additional memory allocation needed for this, but that's mostly done on the arena, so it should hopefully not have a big impact. (And the additional memory allocations can be avoided by disabling retries via a channel arg.)

    Please let me know if you have any questions. Thanks!


    This change is Reviewable

  • Remove memset(0) from arena allocate memory.

    Remove memset(0) from arena allocate memory.

    Callers should properly initialize the memory.

    Note that to avoid performance regressions we need some reordering in the initialization of grpc_call.

    This behavior can be overridden using GRPC_ARENA_INIT_STRATEGY environment variable.

    I had two more changes in the following files which I will skip in the PR because they are purely performance changes for cache coherency. I will upload that as a separate patch once this PR is merged: src/core/lib/channel/channel_stack.cc src/core/lib/surface/call.cc


    This change is Reviewable

  • Channel Tracing Implementation; Part 1

    Channel Tracing Implementation; Part 1

    Implements the basic channel tracing architecture.

    Adds channel_tracer and object_registry files. The tracers are held by channels and subchannels and only log channel creation for now. In a subsequent PR I will begin plumbing the tracing objects around and logging all of the interesting things happening

    Picks up work from #10259. That PR was too stale to do a merge or rebase, but I want to maintain history


    This change is Reviewable

  • Add address sorting submodule for use in c-ares wrapper

    Add address sorting submodule for use in c-ares wrapper

    This adds code to sort IP addresses resolved by grpc/c-ares wrapper per RFC 6724. This used Android's getaddrinfo as a guide (the differences between this and Android's implementation are mostly cosmetic and based around hooking the address-sorting code into the grpc code base). So, the code is added as a custom submodule which is under Android's license.

    I'd like to have more end-to-end tests and cross-platform tests for this, (e.g. run the resolver_component_tests on IPv4-only machines, IPv6-only machines, machines with modified routing tables, Windows, etc.,and verify sorting results in those scenarios), but it looks like that involves a lot of setup, and so this tests by mocking libc functions.


    This change is Reviewable

  • Bazel multipool config update, removed sentinel file

    Bazel multipool config update, removed sentinel file

    Added multipool config for large instances and standard instances, replacing the sentinel file for large instances. Also updated the RBE container to the image containing bazel 0.16.1

  • Integrate Grpc.Tools into msbuild system (C# only)

    Integrate Grpc.Tools into msbuild system (C# only)

    When Grpc.Tools is added to a C# project, the project recognizes .proto files. These .proto are compiled into .cs files placed in the object directory (under obj/...), and are not shown in Visual Studio, but are available to Intellisense nevertheless.

    The scripts support both "classic" projects and the new dotnet style projects. In line with the latter ones (when .cs files are just dropped into the directory are picked up and compiled), .proto files are handled the same way, so just placing a .proto file into the folder is enough to compile it, and compile its protoc outputs into the project target assembly.

    The "classic" project requires adding .proto files by one, and they are assigned a correct build action automatically. To manually add proto files to msbuild script, use 'ProtoBuf' item type.

    For native code C++ projects, there is no added support beyond just dropping the compiler as before. For all other project types, an error message is generated on an attempted build. More C++ support is on the way.

    Dependency change: the package now adds a dependency on Grpc.Tools of a matching version for managed projects only. This is naturally skipped for native C++, as the managed runtime is not required.

    Also packaged are proto includes for well-known types.


    Validated and confirmed working:

    • Windows (VS, classic C#, dotnet C#, C++)
    • Linux/Mono (both classic C# and dotnet C#)
    • Linux/dotnet (dotnet C# project only)

    There are quite a few questions I wanted to discuss. If anyone could help me with proper decicions, I would appreciate it.

    1. The captialization of generated .cs files. When I compile fooBar.proto, the resulting .cs file is called FooBar.proto. Is there a way around that? This does not seem to make sense in the build like this, when the .cs files are treated at best as temporary. I can certainly script around the issue in msbuild scripts, but why have it in the first place?

    2. If x.proto does not contain any RPC services. the corresponding xGrpc.cs is not generated (FWIW, the cpp plugin does not do that). This is not good for the build. While it is certainly possible to see if the file is there after compilation, it is impossible to learn if it was actually produced by it. In other words, if I take a service definition out of x.proto after having previously compiled it, I end up with a stale xGrpc.cs that is added to compilation. Of course, it is possible to write some msbuild incantations about this issue as well, but it would be much cleaner just to create a nearly empty xGrpc.cs stub even if no services are defined. So options I am asking about here are

    • a) Leave it as is and script some very ugly transformations around it.
    • b) Add a plugin option to do always generate the stub.
    • c) In fact, forget the option and just always generate the stub.
    1. I want to package cpp plugins also, and support to integrate gRPC into the build process. (I already have it packaged internally). This will cover the build process in Visual Studio. Should we do that?

    2. I am adding a bunch of files to the root of src/chsarp that only go into the nuget package. Is it better to place them into a subdirectory? Is Grpc.Tools subdirectory good?


    /cc @jskeet @hcoona
    Closes #4805
    /* #13098 */

  • C++ API review: reduce core/implementation leakage

    C++ API review: reduce core/implementation leakage

    If you liked internalization, you'll love C++ API review. The purpose of this PR is to clean up the use of breakable core structs from C++ public API. This has previously been done for the features that interfaced with code generation, but this now needs to be more pervasive. The basic principle is that core surface APIs and C++ implementation details should not leak through to C++ public API.

    The implementation strategy is

    1. when possible, privatize features that should have never been exposed
    2. deprecate pieces if they can be easily and meaningfully substituted with a purely C++ API
    3. co-opt items for which there is no other option, but try to give an alternative and more idiomatically C++ version for those when possible

    This supercedes #14106 and will be matched to a gRFC soon.


    This change is Reviewable

  • Channelz Python wrapper implementation

    Channelz Python wrapper implementation

    See Issue https://github.com/grpc/grpc/issues/17264

    • Expose the C-Core API in Cython layer
    • Handle the object translation
    • Create a separate package for Channelz specifically
    • Adding utilities for the new package
  • Rich status transport implementation

    Rich status transport implementation

    Background

    gRPC spec defined two trailing data to indicate the status of a RPC call Status and Status-Message (Spec). But status code and a text message themselves are insufficient to express more complicate situation like the RPC call failed because of quota check of certain policy, or the stack trace from the crashed server, or obtain retry delay from the server (see error details).

    Objective

    So, gRPC needs a mechanism to transport those complex status. It is implemented in C++, Java, Golang, and now Python.

    Design

    It is quite straight forward, we provide two API:

    • A server API to pack the rich status proto.
    • A client API to unpack the rich status proto.

    The transportation is done by setting/getting a trailing metadata entry named grpc-status-details-bin. Rich status message is encoded by ProtoBuf and transmit as binary.

    Implementation

    This PR

    Related Issue

    Addresses: https://github.com/grpc/grpc/issues/16366

  • Make tcp client posix test more robust

    Make tcp client posix test more robust

    Previous approach to test connection cancellation is not very robust. Even if the backlog specified to listen is 1, the kernel continues to accept a certain number of SYN packets before dropping them. With this approach, we create client sockets in a loop and try to make each socket connect to the listening socket until the connection attempt times out. This loop attempts to identify the number of new connection attempts that will be allowed by the kernel before any subsequent connection attempts become pending indefinitely.

    This bug was unearthed during testing undertaken with event engine endpoints in https://github.com/grpc/grpc/pull/31661 and it caused some flakiness.

  • Make http proxy fixture test more robust

    Make http proxy fixture test more robust

    This fixes bugs in the test. If the connection to the server (client) endpoint fails, we trigger shutdown of the corresponding other connection to client (server). This bug was unearthed during testing undertaken with event engine endpoints in https://github.com/grpc/grpc/pull/31661 and it caused some flakiness.

  • Bump gevent version to avoid Cython cpdef issue

    Bump gevent version to avoid Cython cpdef issue

    What version of gRPC and what language are you using?

    gRPC v1.50.1 and I'm using C++ but this issue is with a Python dependency

    What operating system (Linux, Windows,...) and version?

    Ubuntu 22.04.01 LTS in WSL

    What runtime / compiler are you using (e.g. python version or version of gcc)

    $ gcc --version gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    $ python -V Python 3.10.6

    What did you do?

    $ bazel query //...

    What did you expect to see?

    The list of available labels.

    What did you see instead?

    I get an error when running query. This seems to be due to a dependency on gevent which is too old.

    ERROR: Could not find a version that satisfies the requirement gevent==21.1.2 (from versions: 0.9.2, 0.9.3, 0.10.0, 0.11.0, 0.11.1, 0.11.2, 0.12.0, 0.12.1, 0.12.2, 0.13.0, 0.13.1, 0.13.2, 0.13.3, 0.13.4, 0.13.5, 0.13.6, 0.13.7, 0.13.8, 1.0, 1.0.1, 1.0.2, 1.1a1, 1.1a2, 1.1b1, 1.1b2, 1.1b3, 1.1b4, 1.1b5, 1.1b6, 1.1rc1, 1.1rc2, 1.1rc3, 1.1rc4, 1.1rc5, 1.1.0, 1.1.1, 1.1.2, 1.2a1, 1.2a2, 1.2.0, 1.2.1, 1.2.2, 1.3a1, 1.3a2, 1.3b1, 1.3b2, 1.3.0, 1.3.1, 1.3.2, 1.3.2.post0, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4.0, 1.5a1, 1.5a2, 1.5a3, 1.5a4, 1.5.0, 20.4.0, 20.5.0, 20.5.1, 20.5.2, 20.6.0, 20.6.1, 20.6.2, 20.9.0, 20.12.0, 20.12.1, 21.1.0, 21.1.1, 21.1.2, 21.8.0, 21.12.0, 22.8.0, 22.10.1, 22.10.2)
    ERROR: No matching distribution found for gevent==21.1.2
    Traceback (most recent call last):
      File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
        return _run_code(code, main_globals, None,
      File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
        exec(code, run_globals)
      File "/home/shareefj/.cache/bazel/_bazel_shareefj/ebd63933a37b436858f7ab2b2d82e5ea/external/io_bazel_rules_python/python/pip_install/extract_wheels/__main__.py", line 5, in <module>
        main()
      File "/home/shareefj/.cache/bazel/_bazel_shareefj/ebd63933a37b436858f7ab2b2d82e5ea/external/io_bazel_rules_python/python/pip_install/extract_wheels/__init__.py", line 76, in main
        subprocess.run(pip_args, check=True, env=env)
      File "/usr/lib/python3.10/subprocess.py", line 524, in run
        raise CalledProcessError(retcode, process.args,
    subprocess.CalledProcessError: Command '['/home/shareefj/git/grpc/.venv/bin/python3', '-m', 'pip', '--isolated', 'wheel', '-r', '/home/shareefj/.cache/bazel/_bazel_shareefj/ebd63933a37b436858f7ab2b2d82e5ea/external/com_github_grpc_grpc/requirements.bazel.txt']' returned non-zero exit status 1.
    

    An associated ticket on gevent: https://github.com/gevent/gevent/issues/1801

    If I manually try to install gevent as you have it in requirements.bazel.txt, gevent==21.1.2, I get the same error.

  • installing gpcrio - calculate_macosx_platform_tag doesn't parse 'base_version' correctly

    installing gpcrio - calculate_macosx_platform_tag doesn't parse 'base_version' correctly

    What version of gRPC and what language are you using?

    1.51.1

    What operating system (Linux, Windows,...) and version?

    Mac 12.6

    What runtime / compiler are you using (e.g. python version or version of gcc)

    Python 3.8.15

    What did you do?

    pip install grpcio

    What did you expect to see?

    should install correctly

    What did you see instead?

    File "lib/python3.8/site-packages/wheel/macosx_libfile.py", line 360, in calculate_macosx_platform_tag
      assert len(base_version) == 2
      AssertionError
      ----------------------------------------
      ERROR: Failed building wheel for grpcio
    

    This is happening because distutils.utils.get_platform is returning: macosx-12-x86_64 instead of macosx-12.6-x86_64 and the parsing code expects to see an 12.6 for the version and not 12, so the assert fails

    Anything else we should know about your project / environment?

  • Remove core codegen

    Remove core codegen

    This PR cleans up some functions in class CoreCodegen. Other functions should be cleaned up in a subsequent PR. The ultimate goal is to remove class CoreCodegen and its global pointer g_core_codegen_interface entirely.

Comprehensive RPC framework with support for C++, C#, Java, JavaScript, Python and more.

Ice - Comprehensive RPC Framework Ice helps you network your software with minimal effort. By taking care of all interactions with low-level network p

Nov 28, 2022
PHP Encoder, protect PHP scripts in PHP 8 and PHP 7, High Performance, Compitable with X86_64, MIPS, ARM platform and Ubuntu/Centos/OpenWRT system.

What's FRICC2? FRICC2 is a PHP Script encryption tool. When you are developing a commercial software using PHP, the script can be distributed as encry

Nov 23, 2022
ANSI C library for NURBS, B-Splines, and Bézier curves with interfaces for C++, C#, D, Go, Java, Lua, Octave, PHP, Python, R, and Ruby.

TinySpline TinySpline is a small, yet powerful library for interpolating, transforming, and querying arbitrary NURBS, B-Splines, and Bézier curves. Th

Nov 26, 2022
List of Persian Colors and hex colors for CSS, SCSS, PHP, JS, Python, and Ruby.

Persian Colors (Iranian colors) List of Persian Colors and hex colors for CSS, SCSS, PHP, C++, QML, JS, Python, Ruby and CSharp. Persian colors Name H

Sep 3, 2022
✔️The smallest header-only GUI library(4 KLOC) for all platforms
✔️The smallest header-only GUI library(4 KLOC) for all platforms

Welcome to GUI-lite The smallest header-only GUI library (4 KLOC) for all platforms. 中文 Lightweight ✂️ Small: 4,000+ lines of C++ code, zero dependenc

Dec 4, 2022
Python Inference Script is a Python package that enables developers to author machine learning workflows in Python and deploy without Python.
Python Inference Script is a Python package that enables developers to author machine learning workflows in Python and deploy without Python.

Python Inference Script(PyIS) Python Inference Script is a Python package that enables developers to author machine learning workflows in Python and d

Nov 4, 2022
Fast Binary Encoding is ultra fast and universal serialization solution for C++, C#, Go, Java, JavaScript, Kotlin, Python, Ruby, Swift

Fast Binary Encoding (FBE) Fast Binary Encoding allows to describe any domain models, business objects, complex data structures, client/server request

Dec 1, 2022
Asynchronous gRPC with Boost.Asio executors

asio-grpc This library provides an implementation of boost::asio::execution_context that dispatches work to a grpc::CompletionQueue. Making it possibl

Dec 2, 2022
gRPC - An RPC library and framework Baind Unity 3D Project

Unity 3D Compose for Desktop and Android, a modern UI framework for C ++ , C# that makes building performant and beautiful user interfaces easy and enjoyable.

May 19, 2022
Async GRPC with C++20 coroutine support

agrpc Build an elegant GRPC async interface with C++20 coroutine and libunifex (target for C++23 executor). Get started mkdir build && cd build conan

Nov 15, 2022
A static analyzer for Java, C, C++, and Objective-C
A static analyzer for Java, C, C++, and Objective-C

Infer Infer is a static analysis tool for Java, C++, Objective-C, and C. Infer is written in OCaml. Installation Read our Getting Started page for det

Dec 4, 2022
distributed builds for C, C++ and Objective C

distcc -- a free distributed C/C++ compiler system by Martin Pool Current Documents: https://distcc.github.io/ Formally http://distcc.org/ "pump" func

Nov 29, 2022
Card game with Objective-C using Allegro 4/5
Card game with Objective-C using Allegro 4/5

Card game with Objective-C using Allegro 4/5 , This is an alternative of the real game for personal reasons .

Nov 7, 2021
Binary Ninja plugin & workflow to help analyze Objective-C code
Binary Ninja plugin & workflow to help analyze Objective-C code

Objective Ninja Objective Ninja is a Binary Ninja plugin to assist in reverse engineering Objective-C code. Beware, Objective Ninja is still in very e

Aug 16, 2022
Macro magic for declaring/calling Objective-C APIs from C11 or C++. Preloads selectors, chooses the correct objc_msgSend to call per method/platform.

OC - Easily Declare/Invoke Objective-C APIs from C11 or C++11 Usage // Call class and instance methods: NSWindow* const nswindow = oc_cls(NSWindow,new

Sep 9, 2022
🚀 Coroutine-based concurrency library for PHP

English | 中文 Swoole is an event-driven asynchronous & coroutine-based concurrency networking communication engine with high performance written in C++

Nov 26, 2022
PHP Client based on C++ for Polaris

polaris-php Polaris is an operation centre that supports multiple programming languages, with high compatibility to different application framework. P

Nov 8, 2022
A fast phone number lib for Ruby (binds to Google's C++ libphonenumber)

MiniPhone A Ruby gem which plugs directly into Google's native C++ libphonenumber for extremely fast and robust phone number parsing, validation, and

Oct 30, 2022
Calleree helps to analyze Ruby's caller-callee relationships.

Calleree Calleree helps to analyze Ruby's caller-callee relationships. Note that this tool consumes memory and introduces additional overhead because

Oct 3, 2022
An extra-lightweight Ruby gem for working with SQLite3 databases

Extralite Extralite is an extra-lightweight SQLite3 wrapper for Ruby. It provides a single class with a minimal set of methods to interact with an SQL

Nov 28, 2022