Git Product home page Git Product logo

grpc-c's Introduction

GRPC-C

C implementation of gRPC layered of top of core libgrpc.

Prerequisites

Make sure you have the following install in order to install dependencies

autoconf automake libtool curl make g++ unzip

Build

autoreconf --install
git submodule update --init
./builddeps.sh
mkdir build && cd build
../configure
make
sudo make install

If you want to install dependencies in a different directory other than /usr/local/, use ./buildgen.sh

Examples

cd build/examples
make gencode
make

This should build foo_client and foo_server. To run example code,

sudo ./foo_server test
sudo ./foo_client test

Status

Pre-alpha. Under active development. APIs may change.

Dependencies

  • gRPC v1.3.0
  • protobuf 3.0
  • protobuf-c 1.2.1

grpc-c's People

Contributors

ajhai avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

grpc-c's Issues

Client hang when exec example/client_streaming_client.c

I modified the example client_streaming_client.c and client_streaming_server.c to adapt the newest interface of grpc-c and grpc v1.3.0.

The server can receive data from client, and client hang after sending 10 stream data to server, hanged on grpc_c_client_wait(client);.

If I delete grpc_c_client_wait(client); in client_streaming_client.c, client will exit immediately and didn't send any data to server.

Can you point out how to fix this problem to run example/client_streaming_client.c correctly.

extra "uint32_t flags" in generated client code

Hi Ajay,

I tried the steps, the generated foo.grpc-c.h file has an extra "uint32_t flags" parameter (6 params total), however the caller does not (5 params total), resulting in the following compile error:

foo.grpc-c.h:

int foo__greeter__say_hello (grpc_c_client_t *client, grpc_c_metadata_array_t *a
rray, uint32_t flags, Foo__HelloRequest *input, Foo__HelloReply **output, grpc_c
_status_t *status, long timeout);

../../examples/foo_client.c:46:18: error: too few arguments to function ‘foo__greeter__say_hello’
int status = foo__greeter__say_hello(client, NULL, &h, &r, NULL, -1);

Illegal header key error on trying to set authorization header using metadata

I'm trying to set an auth header for a blocking rpc call from a client by passing metadata array. But the call fails with an error saying illegal header key.

Following is the way I'm trying to set the auth header:
context = grpc_c_context_init(NULL, 1);
grpc_c_metadata_array_init(&metadata);
grpc_c_add_metadata_by_array(&metadata, &context->gcc_metadata_storage, "authorization", "Bearer aabbcc");
int status = say_hello(client, &metadata, 0, &request, &response, NULL, -1);

Following is the error message:
I ev_epoll_linux.c:95 epoll engine will be using signal: 40
D ev_posix.c:107 Using polling engine: epoll
D dns_resolver.c:316 Using native dns resolver
E call.c:850 validate_metadata: {"created":"@1534133244.545845474","description":"Illegal header key","file":"src/core/lib/surface/validate_metadata.c","file_line":56,"offset":0,"raw_bytes":"41 75 74 68 6f 72 69 7a 61 74 69 6f 6e 'Authorization'"}
E context.c:157 Freeing context that is still in use
E client.c:1114 Failed to finish batch operations on sync call: 10

Is this the correct way to set the Authorization header? Can you please point to an example?

unable to make on ubuntu 17.04

Having this error while making,

root@kumaran:~/grpc-c/build# make make all-recursive make[1]: Entering directory '/root/grpc-c/build' Making all in compiler make[2]: Entering directory '/root/grpc-c/build/compiler' depbase=echo ../third_party/protobuf-c/protoc-c/c_bytes_field.o | sed 's|[^/]*$|.deps/&|;s|.o$||';\ g++ -DHAVE_CONFIG_H -I. -I../../compiler -I.. -I../../compiler -I../../compiler/../third_party/protobuf-c -I../../compiler/../third_party/protobuf-c/protobuf-c -g -O2 -MT ../third_party/protobuf-c/protoc-c/c_bytes_field.o -MD -MP -MF $depbase.Tpo -c -o ../third_party/protobuf-c/protoc-c/c_bytes_field.o ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc &&\ mv -f $depbase.Tpo $depbase.Po In file included from ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc:63:0: ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.h:89:3: error: ‘map’ does not name a type map<string, string> variables_; ^~~ ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc:77:25: error: ‘map’ has not been declared map<string, string>* variables) { ^~~ ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc:77:28: error: expected ‘,’ or ‘...’ before ‘<’ token map<string, string>* variables) { ^ ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc: In function ‘void google::protobuf::compiler::c::SetBytesVariables(const google::protobuf::FieldDescriptor*, int)’: ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc:78:5: error: ‘variables’ was not declared in this scope (*variables)["name"] = FieldName(descriptor); ^~~~~~~~~ ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc: In constructor ‘google::protobuf::compiler::c::BytesFieldGenerator::BytesFieldGenerator(const google::protobuf::FieldDescriptor*)’: ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc:89:34: error: ‘variables_’ was not declared in this scope SetBytesVariables(descriptor, &variables_); ^~~~~~~~~~ ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc: In member function ‘virtual void google::protobuf::compiler::c::BytesFieldGenerator::GenerateStructMembers(google::protobuf::io::Printer*) const’: ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc:101:22: error: ‘variables_’ was not declared in this scope printer->Print(variables_, "ProtobufCBinaryData $name$$deprecated$;\n"); ^~~~~~~~~~ ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc: In member function ‘virtual void google::protobuf::compiler::c::BytesFieldGenerator::GenerateStaticInit(google::protobuf::io::Printer*) const’: ../../compiler/../third_party/protobuf-c/protoc-c/c_bytes_field.cc:142:22: error: ‘variables_’ was not declared in this scope printer->Print(variables_, "$default_value$"); ^~~~~~~~~~ Makefile:519: recipe for target '../third_party/protobuf-c/protoc-c/c_bytes_field.o' failed make[2]: *** [../third_party/protobuf-c/protoc-c/c_bytes_field.o] Error 1 make[2]: Leaving directory '/root/grpc-c/build/compiler' Makefile:464: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/root/grpc-c/build' Makefile:375: recipe for target 'all' failed make: *** [all] Error 2

And tried to resolve with this solution. The errors are repeated for other components like set and queue and so on. The same is reproducible for mint versions as well. I bet in other evn too.

misprint in ./builddeps.sh

Hello,
Seems like there is a misprint in ./builddeps.sh, line 21.
Current line:
./autogen.sh && ./configure --prefix=${pfx} && make && sudo make prefix=${pfix} install
Should be:
./autogen.sh && ./configure --prefix=${pfix} && make && sudo make prefix=${pfix} install

Notice ${pfx} is changed to ${pfix}
There is no variable named 'pfx' and as a result the prefix is set to an empty string.

../configure fails

What operating system (Linux, Windows, …) and version?
MacOS 10.14.5

What did you do?
I cloned the repo using :
$ git clone https://github.com/Juniper/grpc-c.git

I installed required dependencies as described in the gRPC docs.

Then I did
$ cd grpc-c
$ autoreconf --install
$ git submodule update --init
$ ./builddeps.sh

then -
$mkdir build && cd build
$ ../configure
Error!

What did you expect to see?
Something beautiful!
I expected to see the grpc-c compile nicely.

What did you see instead?
Here, I get the following error :

checking for stdio.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking for unistd.h... (cached) yes
checking grpc/grpc.h usability... no
checking grpc/grpc.h presence... no
checking for grpc/grpc.h... no
configure: error: Could not find grpc.h anywhere, install grpc

I have installed grpc.

gRPC-c server does not work with client implemented with other languages

@ajhai
I tested with the 'helloworld' examples .
I started the server implemented with grpc-c, and i implemented the client with go lang and c++. I found out that these client(implemented with go\c++) could not get the response from the server(grpc-c server), and had been blocked.
The client implemented with grpc-c works well.

build failed on ubuntu 16.04

make all-recursive
make[1]: Entering directory '/code/cogmeta/vendor/grpc-c/build'
Making all in compiler
make[2]: Entering directory '/code/cogmeta/vendor/grpc-c/build/compiler'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/code/cogmeta/vendor/grpc-c/build/compiler'
Making all in lib
make[2]: Entering directory '/code/cogmeta/vendor/grpc-c/build/lib'
depbase=echo client.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||';
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../lib -I.. -I../../lib -I../../lib/h -I../../l
ib/../third_party/protobuf-c -g -O2 -MT client.lo -MD -MP -MF $depbase.Tpo -c -o client.lo ../../lib/client.c &&
mv -f $depbase.Tpo $depbase.Plo
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../lib -I.. -I../../lib -I../../lib/h -I../../lib/../third_party/protobuf-c -g
-O2 -MT client.lo -MD -MP -MF .deps/client.Tpo -c ../../lib/client.c -fPIC -DPIC -o .libs/client.o
../../lib/client.c: In function ‘gc_client_create_by_host’:
../../lib/client.c:82:43: error: too few arguments to function ‘grpc_completion_queue_create’
client->gcc_channel_connectivity_cq = grpc_completion_queue_create(NULL);
^
In file included from ../../lib/h/grpc-c/grpc-c.h:14:0,
from ../../lib/client.c:6:
/usr/local/include/grpc/grpc.h:98:32: note: declared here

SSL credential setting sample needed

I am trying to use this library to make a secure connection to my server. However I could not find any sample which does a secure connection to server in GRPC-C.

In C++ its straight forward:
grpc::SslCredentialsOptions opts =
{"zzz","xxxx","",""}
auto channel_creds = grpc::SslCredentials(opts);

Unable to find any sample/example to achieve the same with GRPC-C. Is it supported?
I am new to this, sorry if the question has a very straightforward answer.

What is the use of the generated'has_'

@ajhai , Hello, My .proto file defined the message KillRequest as below,

message KillRequest {
        string id = 1;
	bool force = 2;
	uint32 timeout = 3;
}

I used "make lcrd.grpc-c.c" generated the code, found that the struct _KillRequest has the protobuf_c_boolean has_force; and protobuf_c_boolean has_timeout.
I want to know why we add these two varibales,and what is the use of them. And I tested the code,found that we must fill them with true,otherwise,the grpc server could not recevice the right message.
I readed the grpc-c code, but i did not quit understand that. Please tell me something about that,THX

struct  _KillRequest
{
  ProtobufCMessage base;
  char *id;
  **protobuf_c_boolean has_force;**
  protobuf_c_boolean force;
  **protobuf_c_boolean has_timeout;**
  uint32_t timeout;
};

How to make grpc-c for embedded Linux using buildroot

Hi, I want to compile grpc-c for the embedded system using bulldroot, could you tell me how this can be done?

Usually it's enough just to specify arm-buildroot-linux-gnueabihf-gcc instead of gcc in Makefile;
How do I change the instruction set to achieve this?
autoreconf --install
git submodule update --init
./builddeps.sh
mkdir build && cd build
../configure
make

Thank you!

Unable to make under Debian 8.6

Hi,
I completed the following steps before this issue:

  1. git clone https://github.com/grpc/grpc.git & make install
  2. git clone https://github.com/google/protobuf.git & make install
    3)git clone https://github.com/protobuf-c/protobuf-c.git & make install
  3. git clone https://github.com/Juniper/grpc-c.git
  4. due to same name space issue as issue#19, I linked the protobuf-c from step 3 to the third_party directory
    but I hit this issue that needs help, thx

David

libtool: link: g++ -I../../compiler -I../../compiler/../third_party/protobuf-c -I../../compiler/../third_party/protobuf-c/protobuf-c -g -O2 -o protoc-gen-grpc-c ../third_party/protobuf-c/protoc-c/c_bytes_field.o ../third_party/protobuf-c/protoc-c/c_enum.o ../third_party/protobuf-c/protoc-c/c_enum_field.o ../third_party/protobuf-c/protoc-c/c_extension.o ../third_party/protobuf-c/protoc-c/c_field.o ../third_party/protobuf-c/protoc-c/c_file.o ../third_party/protobuf-c/protoc-c/c_generator.o ../third_party/protobuf-c/protoc-c/c_helpers.o ../third_party/protobuf-c/protoc-c/c_message.o ../third_party/protobuf-c/protoc-c/c_message_field.o ../third_party/protobuf-c/protoc-c/c_primitive_field.o ../third_party/protobuf-c/protoc-c/c_service.o ../third_party/protobuf-c/protoc-c/c_string_field.o grpc_c_file.o grpc_c_generator.o grpc_c_helpers.o grpc_c_message.o grpc_c_service.o main.o /usr/local/lib/libprotobuf.a /usr/local/lib/libprotoc.a
/usr/local/lib/libprotoc.a(plugin.o): In function google::protobuf::compiler::CodeGeneratorRequest::compiler_version() const': /home/david/dev/protobuf/src/./google/protobuf/compiler/plugin.pb.h:1041: undefined reference to google::protobuf::compiler::Version_default_instance'
/usr/local/lib/libprotoc.a(plugin.o): In function GeneratorResponseContext': /home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:71: undefined reference to google::protobuf::compiler::Version::Version(google::protobuf::compiler::Version const&)'
/usr/local/lib/libprotoc.a(plugin.o): In function ~GeneratorResponseContext': /home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:72: undefined reference to google::protobuf::compiler::Version::~Version()'
/home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:72: undefined reference to google::protobuf::compiler::Version::~Version()' /usr/local/lib/libprotoc.a(plugin.o): In function google::protobuf::compiler::PluginMain(int, char**, google::protobuf::compiler::CodeGenerator const*)':
/home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:158: undefined reference to google::protobuf::compiler::CodeGeneratorRequest::CodeGeneratorRequest()' /home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:166: undefined reference to google::protobuf::compiler::CodeGeneratorResponse::CodeGeneratorResponse()'
/home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:166: undefined reference to google::protobuf::compiler::CodeGeneratorResponse::~CodeGeneratorResponse()' /home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:180: undefined reference to google::protobuf::compiler::CodeGeneratorRequest::~CodeGeneratorRequest()'
/home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:180: undefined reference to google::protobuf::compiler::CodeGeneratorRequest::~CodeGeneratorRequest()' /home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:166: undefined reference to google::protobuf::compiler::CodeGeneratorResponse::~CodeGeneratorResponse()'
/usr/local/lib/libprotoc.a(plugin.o): In function google::protobuf::compiler::Version::operator=(google::protobuf::compiler::Version const&)': /home/david/dev/protobuf/src/./google/protobuf/compiler/plugin.pb.h:107: undefined reference to google::protobuf::compiler::Version::CopyFrom(google::protobuf::compiler::Version const&)'
/usr/local/lib/libprotoc.a(plugin.o): In function CreateInternal<google::protobuf::compiler::CodeGeneratorResponse_File>': /home/david/dev/protobuf/src/./google/protobuf/arena.h:750: undefined reference to google::protobuf::compiler::CodeGeneratorResponse_File::CodeGeneratorResponse_File()'
/home/david/dev/protobuf/src/./google/protobuf/arena.h:682: undefined reference to google::protobuf::compiler::CodeGeneratorResponse_File::CodeGeneratorResponse_File()' /usr/local/lib/libprotoc.a(plugin.o): In function google::protobuf::Arena::AllocHook(std::type_info const*, unsigned long) const':
/home/david/dev/protobuf/src/./google/protobuf/arena.h:692: undefined reference to typeinfo for google::protobuf::compiler::CodeGeneratorResponse_File' /usr/local/lib/libprotoc.a(plugin.o): In function CreateInternalgoogle::protobuf::compiler::CodeGeneratorResponse_File':
/home/david/dev/protobuf/src/./google/protobuf/arena.h:750: undefined reference to google::protobuf::compiler::CodeGeneratorResponse_File::CodeGeneratorResponse_File()' /home/david/dev/protobuf/src/./google/protobuf/arena.h:682: undefined reference to google::protobuf::compiler::CodeGeneratorResponse_File::CodeGeneratorResponse_File()'
/usr/local/lib/libprotoc.a(plugin.o): In function google::protobuf::Arena::AllocHook(std::type_info const*, unsigned long) const': /home/david/dev/protobuf/src/./google/protobuf/arena.h:692: undefined reference to typeinfo for google::protobuf::compiler::CodeGeneratorResponse_File'
/usr/local/lib/libprotoc.a(plugin.o): In function google::protobuf::compiler::GeneratorResponseContext::~GeneratorResponseContext()': /home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:72: undefined reference to google::protobuf::compiler::Version::~Version()'
/usr/local/lib/libprotoc.a(plugin.o): In function ~GeneratorResponseContext': /home/david/dev/protobuf/src/google/protobuf/compiler/plugin.cc:72: undefined reference to google::protobuf::compiler::Version::~Version()'
collect2: error: ld returned 1 exit status
Makefile:477: recipe for target 'protoc-gen-grpc-c' failed
make[2]: *** [protoc-gen-grpc-c] Error 1
make[2]: Leaving directory '/home/david/dev/grpc-c/build/compiler'
Makefile:452: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/david/dev/grpc-c/build'
Makefile:362: recipe for target 'all' failed
make: *** [all] Error 2

incompatible with current gRPC head

Seeing errors like this:

../../lib/client.c:82:43: error: too few arguments to function ‘grpc_completion_queue_create’
     client->gcc_channel_connectivity_cq = grpc_completion_queue_create(NULL);
                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../lib/h/grpc-c/grpc-c.h:14:0,
                 from ../../lib/client.c:6:
/usr/local/include/grpc/grpc.h:98:32: note: declared here
 GRPCAPI grpc_completion_queue *grpc_completion_queue_create(
                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/client.c: In function ‘gc_client_prepare_async_ops’:
../../lib/client.c:580:23: error: too few arguments to function ‘grpc_completion_queue_create’
     context->gcc_cq = grpc_completion_queue_create(NULL);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../lib/h/grpc-c/grpc-c.h:14:0,
                 from ../../lib/client.c:6:
/usr/local/include/grpc/grpc.h:98:32: note: declared here
 GRPCAPI grpc_completion_queue *grpc_completion_queue_create(
                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/client.c: In function ‘gc_client_prepare_sync_ops’:
../../lib/client.c:746:23: error: too few arguments to function ‘grpc_completion_queue_create’
     context->gcc_cq = grpc_completion_queue_create(NULL);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../lib/h/grpc-c/grpc-c.h:14:0,
                 from ../../lib/client.c:6:
/usr/local/include/grpc/grpc.h:98:32: note: declared here
 GRPCAPI grpc_completion_queue *grpc_completion_queue_create(
                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/client.c: In function ‘gc_client_prepare_unary_ops’:
../../lib/client.c:877:23: error: too few arguments to function ‘grpc_completion_queue_create’
     context->gcc_cq = grpc_completion_queue_create(NULL);
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../lib/h/grpc-c/grpc-c.h:14:0,
                 from ../../lib/client.c:6:
/usr/local/include/grpc/grpc.h:98:32: note: declared here
 GRPCAPI grpc_completion_queue *grpc_completion_queue_create(
                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

grpc_c_server_add_insecure_http2_port should return 0 on failure

Hi,

Currently grpc_c_server_add_insecure_http2_port is returning 1 for failure:

int
grpc_c_server_add_insecure_http2_port (grpc_c_server_t server,
const char
addr)
{
if (server == NULL) return 1;

return grpc_server_add_insecure_http2_port(server->gcs_server, addr);

}

But according to grpc doc, it should return 0 on failure: (not the normal pattern)

"
GRPCAPI int grpc_server_add_insecure_http2_port ( grpc_server * server,
const char * addr
)

Add a HTTP2 over plaintext over tcp listener.

Returns bound port number on success, 0 on failure. REQUIRES: server not started
"

Query regarding usage of bytes in grpc-c

Hi Ajay,

I am using a bytes in proto and allocating memory(using malloc) while sending raw bytes to peer. Will GRPC-C free this memory or does application should free it.

Thanks and Regards
Raghu. S

grpc_c_init return failure?

Hi Ajay,

Can grpc_c_init() ever fail? If so can the function be changed to return a success/failure status code? Thanks.

Memory leak in the example file "foo_client.c"

    foo__HelloReply *r;

    char str[BUFSIZ];
    snprintf(str, BUFSIZ, "world");
    h.name = str;

    /*
     * This will invoke a blocking RPC
     */
    int status = foo__greeter__say_hello__sync(client, &h, &r, NULL, 0);
    printf("Got back: %s\n", r->message);
    printf("Finished with %d\n", status

In the example file foo_client.c ,the memory pointed by the "foo__HelloReply *r" hadn't free. I added "create_response_free(NULL,r);" to free the memory.Please tell me, Is it OK?

SSL credential failed

code is:

read ca 、cert、key function:
`

int grpc_load_file(const char *filename, int add_null_terminator,
grpc_slice *output) {
unsigned char *contents = NULL;
size_t contents_size = 0;
grpc_slice result = grpc_empty_slice();
FILE *file;
size_t bytes_read = 0;
int ret = 0;
file = fopen(filename, "rb");
if (file == NULL) {
    log_error("fopen %s failed!, err: %s", filename, strerror(errno));
    ret = -1;
    goto end;
}
fseek(file, 0, SEEK_END);
/* Converting to size_t on the assumption that it will not fail */
contents_size = (size_t)ftell(file);
fseek(file, 0, SEEK_SET);
contents = gpr_malloc(contents_size + (add_null_terminator ? 1 : 0));
bytes_read = fread(contents, 1, contents_size, file);
if (bytes_read < contents_size) {
    log_error("fread %s failed!, err: %s", filename, strerror(errno));
    ret = -1;
    goto end;
}
if (add_null_terminator) {
    contents[contents_size++] = 0;
}
result = grpc_slice_new(contents, contents_size, gpr_free);
end:
*output = result;
if (file != NULL) fclose(file);
return ret;

}`

connect to grpc server:
`

ret = grpc_load_file("/etc/cnq-agent/certs/grpc-ca.crt", 1, &ca_slice);
    if (ret < 0)
    {
        log_error("grpc_load_file ca failed!");
        return;
    }
    ret = grpc_load_file("/etc/cnq-agent/certs/grpc-client.crt", 1, &cert_slice);
    if (ret < 0)
    {
        log_error("grpc_load_file cert failed!");
        return;
    }
    ret = grpc_load_file("/etc/cnq-agent/certs/grpc-client.key", 1, &key_slice);
    if (ret < 0)
    {
        log_error("grpc_load_file cert failed!");
        return;
    }
    const char *ca_cert = (const char *)GRPC_SLICE_START_PTR(ca_slice);
    log_debug("ca cert = %s", ca_cert);
    pem_key_cert_pair.private_key = (const char *)GRPC_SLICE_START_PTR(key_slice);
    pem_key_cert_pair.cert_chain = (const char *)GRPC_SLICE_START_PTR(cert_slice);
    grpc_channel_credentials *ssl_creds = grpc_ssl_credentials_create(
        ca_cert, NULL, NULL);
    if (ssl_creds == NULL)
    {
        log_error("grpc_ssl_credentials_create failed!");
        return;
    }
    /*
    * Create a client object with client name as client_streaming client to
    * be talking to a insecure server
    */
    s_client = grpc_c_client_init_by_host("CNQ:9445", "client streaming client", ssl_creds,
        NULL);
    if (s_client == NULL)
    {
        log_error("grpc_c_client_init_by_host failed!");
        return;
    }`

err info:
ssl_transport_security.c:937 Handshake failed with fatal error SSL_ERROR_SSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed.

can you help me? why?

Compilation Failure on MacOS 10.12.5

Compilation failure on MacOS 10.12.5
$ xcode-select --install
..
$ brew install autoconf automake libtool shtool
..
$ brew install gflags
..
$ make
In file included from ../../lib/client.c:12:
../../lib/context.h:6:9: warning: 'GPRC_C_INTERNAL_CONTEXT_H' is used as a header guard here, followed by #define of a different macro [-Wheader-guard]
#ifndef GPRC_C_INTERNAL_CONTEXT_H
^~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/context.h:7:9: note: 'GRPC_C_INTERNAL_CONTEXT_H' is defined here; did you mean 'GPRC_C_INTERNAL_CONTEXT_H'?
#define GRPC_C_INTERNAL_CONTEXT_H
^~~~~~~~~~~~~~~~~~~~~~~~~
GPRC_C_INTERNAL_CONTEXT_H
../../lib/client.c:82:76: error: too few arguments to function call, expected 3, have 1
client->gcc_channel_connectivity_cq = grpc_completion_queue_create(NULL);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
/usr/local/include/grpc/grpc.h:98:9: note: 'grpc_completion_queue_create' declared here
GRPCAPI grpc_completion_queue *grpc_completion_queue_create(

Import the "google/protobuf/empty.proto" and "google/protobuf/any.proto

My .proto file import the "google/protobuf/empty.proto" and "google/protobuf/any.proto", like this:

syntax = "proto3";

import "google/protobuf/empty.proto";
import "google/protobuf/any.proto";

I use "make lcrd.grpc-c.c" generated file,when I use "make" to build the code ,I find the google/protobuf/empty.proto.h can not find.

root@docker-RH2288H-V3:/home/lifeng/gRPC_c/grpc-c/build/lcrd# make lcrd.grpc-c.c
protoc -I ../../lcrd --grpc-c_out=. --plugin=protoc-gen-grpc-c=../compiler/protoc-gen-grpc-c ../../lcrd/lcrd.proto
root@docker-RH2288H-V3:/home/lifeng/gRPC_c/grpc-c/build/lcrd# make 
gcc -DHAVE_CONFIG_H -I. -I../../lcrd -I..    -I. -I../../lcrd/../lib/h/ -I../../lcrd/../third_party/protobuf-c -I../../lcrd/../third_party/grpc/include -g -O2 -MT lcrd_client.o -MD -MP -MF .deps/lcrd_client.Tpo -c -o lcrd_client.o ../../lcrd/lcrd_client.c
In file included from ../../lcrd/lcrd_client.c:8:0:
**./lcrd.grpc-c.h:23:41: fatal error: google/protobuf/empty.proto.h: No such file or directory**
compilation terminated.
Makefile:447: recipe for target 'lcrd_client.o' failed
make: *** [lcrd_client.o] Error 1

gRPC-C server receives zero data from sync client.

message MotionVector{
int32 s_x = 1;
int32 s_y = 2;
int32 d_x = 3;
int32 d_y = 4;
}

message MotionVectors{
repeated MotionVector mv = 1;
}

service MVService{
rpc SayHello (MotionVectors) returns (MVReply){}
}

The server can successfully unpack the data, and the n_mv has the correct value. But s_x, s_y, d_x and d_y are not existing by using has_s_x and so on.

How to enable TCP socket?

Hi,

I would like to try to start the server and listen to the remote connection. However, after starting the foo_server and use netstat to check if the server is listening, I noticed the server is waiting for the Unix socket. May I know how can I use TCP socket instaed of Unix socket. Thank you.

./builddeps.sh fails :

What operating system (Linux, Windows, …) and version?
MacOS 10.14.5

What did you do?
I cloned the repo using :
$ git clone https://github.com/Juniper/grpc-c.git

I installed required dependencies as described in the gRPC docs.

Then I did
$ cd grpc-c
$ autoreconf --install
$ git submodule update --init
Up till here, everything works fine.

$ ./builddeps.sh

What did you expect to see?
Something beautiful!
I expected to see the grpc-c compile nicely.

What did you see instead?
Here, I get the following error :

11 warnings generated.
CXX protoc-c/protoc_c-main.o
CXXLD protoc-c/protoc-c
libtool: warning: library '/usr/local/lib/libprotobuf.la' was moved.
libtool: warning: library '/usr/local/lib/libprotoc.la' was moved.
libtool: error: cannot find the library '/lib/libprotobuf.la' or unhandled argument '/lib/libprotobuf.la'
make: *** [protoc-c/protoc-c] Error 1

I can see libprotobuf.la in /usr/local/lib, so I don't know why it would be complaining that it moved, or that it can't find it.

Calls to raw malloc/free

For use in embedded environments, grpc-c should instead call grpc's gpr_malloc, gpr_realloc, gpr_free.

syntax error near unexpected token `PROTOBUF_C,'

after make step in installation

checking for unistd.h... (cached) yes
checking grpc/grpc.h usability... yes
checking grpc/grpc.h presence... yes
checking for grpc/grpc.h... yes
../configure: line 16221: syntax error near unexpected token `PROTOBUF_C,'
../configure: line 16221: `PKG_CHECK_MODULES(PROTOBUF_C, libprotobuf-c >= 1.2.1)'

I apologize if this this too simple! My guess is that I have made a mistake installing the protocol buffers. Looking at the dependencies:
gRPC v1.3.0
Use correct version:
git checkout -b test v1.3.0
Then followed install.md

protobuf 3.0
protobuf-c 1.2.1

I am not sure of the steps to meet these requirements. Does the Makefile install them for me as the Protoc section seems to suggest? Is this a separate step? Is not related to the problem that I am having?

No rule to make target '/usr/local/lib/libprotobuf.a'

Following build instructions for grpc-c.

autoreconf --install
git submodule update --init
mkdir build && cd build
../configure
make
sudo make `install`

../configure runs and completes
make fails:

g++ -DHAVE_CONFIG_H -I. -I../../compiler -I..    -I../../compiler -I../../compiler/../third_party/protobuf-c -I../../compiler/../third_party/protobuf-c/protobuf-c -g -O2 -MT main.o -MD -MP -MF $depbase.Tpo -c -o main.o ../../compiler/main.cc &&\
mv -f $depbase.Tpo $depbase.Po
make[2]: *** No rule to make target '/usr/local/lib/libprotobuf.a', needed by 'protoc-gen-grpc-c'.  Stop.
make[2]: Leaving directory '/home/grpc-c/build/compiler'
Makefile:464: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/grpc-c/build'
Makefile:375: recipe for target 'all' failed
make: *** [all] Error 2

I believe that I have the correct versions of the dependencies installed. What could be causing this error? Why wouldn't the MAKEFILE have a required rule? Any help would be appreciated.

I doubt it is related, but after running autoreconf --install I get :
aclocal: warning: couldn't open directory 'm4': No such file or directory
and then it continues on as normal.

Each "async" client method consumes a thread

With the C++ bindings, the Async*() methods impose no threading model on the client. I can start an async method, then separately on my own thread(s) call cq->Next() and dispatch the completions however I wish. I can service many simultaneous client requests on few threads this way. This is critical for constrained environments.

With grpc-c, the *__async() functions behave differently. "async" seems to mean "answered asynchronously to the caller". But each __async() call consumes a thread, since internally, they call grpc_completion_queue_next(), which blocks until that particular tag completes. So if I start another client, it will see that the thread pool is full (due to grpc_completion_queue_next blocking each thread) and so will spin up another thread, which itself will block on grpc_completion_queue_next.

I'm curious if this is by design? I would like an option to opt out of the thread pool, and call ..._next() myself.

I see the (unfinished) references to coroutines, and while I have used coroutines before and appreciate them, it still imposes a threading model on the caller.

Do you have plans for allowing the caller to manage the completion queues themselves? I might be able to help, but first want to understand your plans.

Thanks!

The server write function `context->gcc_writer->write()` still return success, when the client had been killed

@ajhai
Hello :
I started a streaming server for test. My .proto file descriped the grpc service as below, the 'events' RPC is a streaming RPC.
I started the event grpc client, and the server wrote the responses to the client. The client got the responses successfully. But when I killed the client with (kill -9 PID), the server still sent the responses successfully, the function context->gcc_writer->write() returned 0.
In my opinion, when i killed the client with (kill -9 PID), the server write function context->gcc_writer->write() should return fail. But now , it still return success, is this a bug? Is there any other ways to check the connections with the clients?

service ContainerService {
	rpc Create(CreateRequest) returns (CreateResponse);
        rpc Start(StartRequest) returns (StartResponse);
        rpc Kill(KillRequest) returns (KillResponse);
	rpc Delete(DeleteRequest) returns (DeleteResponse);
	rpc Info(InfoRequest) returns (InfoResponse);
	rpc List(ListRequest) returns (ListResponse);
	rpc Events(EventsRequest) returns (stream Event);
}

./buildgen.sh not found

Hi,

I follow the build steps, but the following "./buildgen.sh" script is not found under the grpc-c directory:

autoreconf --install
git submodule update --init
./buildgen.sh

Thanks!

example foo_server foo_client don't not work.

i clone the code from https://github.com/Juniper/grpc-c.git
after built it, i started to test the example in grpc-c/build/examples.
when i run the example code(foo_server, foo_client), foo_server doesn't receive the request from foo_client.
i looked into socket info for foo_server, I found foo_server is listen on IPv6 for 127.0.0.1:3000, it doesn't make sense. because 127.0.0.1 should be for IPv4. And foo_client seems send data to wrong interface. foo_client should send data on 127.0.0.1:3000, right?

  1. why foo_server listen on IPv6 for 127.0.0.1? does it due to foo_server can't receive data from foo_client ?
  2. how to specify the foo_server listen on IPv4 ?
  3. why foo_client send data to wrong interface? In my testing, foo_client send data to 172.xxx.xxx.xxx:3128, the interface and port seems both wrong. (note: i didn't modify any code)
  4. how to set foo_client send data on specified interface & port?

the steps are follows:
console 1:
$sudo foo_server test

console 2:
$sudo foo_client test

console 3:
$sudo lsof -i -n -P
foo_serve 14209 root 6u IPv6 522525 0t0 TCP 127.0.0.1:3000 (LISTEN)
foo_clien 14226 root 7u IPv6 522640 0t0 TCP 192.168.xxx.xxx:49312->172.xxx.xxx.xxx:3128 (SYN_SENT)

does any one encounter the same issue?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.