protobuf-c / protobuf-c-rpc Goto Github PK

protobuf.socketrpc uses a slightly more complex rpc wrapper (along with a .proto definition), which is incompatible with protobuf-c-rpc's fixed size header/response.

Using this, protobuf-c-rpc could be scriptable in Java/Python as an example.

As in https://github.com/protobuf-c/protobuf-c/blob/master/protobuf-c/libprotobuf-c.pc.in , the build process should generate a pc file that pkg-config can use.

Hi, I want to compile protobuf-c-rpc 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;
and need to change output directories in make install from
/usr/local/include/ and /usr/local/lib/ to
.../buildroot/output/target/usr/include and .../buildroot/output/target/usr/lib for example:

How do I change the instruction set to achieve this?

Protocol: https://raw.githubusercontent.com/libp2p/js-libp2p-secio/master/src/handshake/secio.proto.js (the Propose protocol)
Data(hex): 0a10cb5d0c1c2adbdf1ec86f731725ac04e512ab02080012a60230820122300d06092a864886f70d01010105000382010f003082010a0282010100d0da1c02f3f66ef502ab1e741c9be07e8e2f013959443c1714148745f9d8cdc3f40e43276835620a7358350d577c19beea7cb50a7ce746412a48632d9622862567a356fe1121517996c25097db4e2c83c2d470e7ed7680e8bbe5af44e7cab9cb3b75420522b770995ad214b28945de8e886ad8afa92ef122144ba2ae95b5ae78eefdcb3b680dd2ce79b9ed23e1d409960027b101205a80b6f40cfe80fac560e9f35b98d4ec43b2c6ebe8cd6a88594f9cb1a1bc011a7426c332e5d7ccbe0aa591687b17716770530b3aa54e7b52457155792c21c399801379355139fcf7ccc7d3d9c3d4474345cc59b994eb542d13ed018178d1c2ed23a22c0ab9d039c6e347a102030100011a11502d3235362c502d3338342c502d35323122184145532d3235362c4145532d3132382c426c6f77666973682a0d5348413235362c534841353132

see protobuf-c/protobuf-c#92

May use golang grpc server with protobuf-c-rpc grpc client?

see protobuf-c/protobuf-c#110

Should I be able to invoke gRPC/C++ servers with this c-rpc API?

If so, I'm getting errors, but I want to make sure this is supported before I file a proper issue.

⇒ make
GEN t/test.pb-c.c
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax specified for the proto file: t/test.proto. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
/Applications/Xcode.app/Contents/Developer/usr/bin/make all-am
CC protobuf-c-rpc/protobuf-c-rpc-data-buffer.lo
CC protobuf-c-rpc/protobuf-c-rpc-dispatch.lo
CC protobuf-c-rpc/protobuf-c-rpc-client.lo
CC protobuf-c-rpc/protobuf-c-rpc-server.lo
CCLD protobuf-c-rpc/libprotobuf-c-rpc.la
Undefined symbols for architecture x86_64:
"_protobuf_c_buffer_simple_append", referenced from:
_server_connection_response_closure in protobuf-c-rpc-server.o
"_protobuf_c_message_check", referenced from:
_client_serialize in protobuf-c-rpc-client.o
_server_serialize in protobuf-c-rpc-server.o
"_protobuf_c_message_free_unpacked", referenced from:
_handle_client_fd_events in protobuf-c-rpc-client.o
_handle_server_connection_events in protobuf-c-rpc-server.o
"_protobuf_c_message_get_packed_size", referenced from:
_client_serialize in protobuf-c-rpc-client.o
_server_serialize in protobuf-c-rpc-server.o
"_protobuf_c_message_pack_to_buffer", referenced from:
_client_serialize in protobuf-c-rpc-client.o
_server_serialize in protobuf-c-rpc-server.o
"_protobuf_c_message_unpack", referenced from:
_client_deserialize in protobuf-c-rpc-client.o
_server_deserialize in protobuf-c-rpc-server.o
"_protobuf_c_service_destroy", referenced from:
_protobuf_c_rpc_server_destroy in protobuf-c-rpc-server.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[1]: *** [protobuf-c-rpc/libprotobuf-c-rpc.la] Error 1
make: *** [all] Error 2

I think this function protobuf_c_dispatch_run must return int code.
I apply this code to project but can't handle when "rpc timeout" or "rpc ok".
Maybe get return error from poll and 0 when "rpc ok"

When a new connection is made, the accept() system call returns a file descriptor that is used to perform all subsequent communication for a given session.

That FD is maintained in:

struct _ServerConnection
{
  int fd;
...

Now, this structure is private and thus no advertised API.

However, I would like to access this FD as I would like to use it to use it with getsockopt().

Currently I have to copy the structure definitions of struct _ServerConnection and struct _ServerRequest into my code and resolve it using the closure data as follows:

int func(void *closure_data)
{
        ServerRequest *server_request = closure_data;
        ServerConnection *conn = server_request->conn;
        struct ucred cred;
        socklen_t len = sizeof(cred);

        if (getsockopt(conn->fd, SOL_SOCKET, SO_PEERCRED, &cred, &len) < 0)
...

This is a hack that I would like to avoid. Is there a way to access the FD using the API? If not, I would be willing to write a patch. But I am not sure how such a patch would look like as there are 2 options:

• make the FD available, i.e. return the FD number

• provide wrapper API calls around getsockopt (e.g. one API call to obtain SO_PEERCRED, one for another call).

I would lean towards the first option.

hi, im trying to implement the dispatcher's poll mode into epoll mode, but when i read the code, i found some questions:
why does the function protobuf_c_rpc_dispatch_run have to allocate and copy and then free over and over again? Maybe its better to create a thread-private pollfd, and update it instead of allocating and using it just one time?
Maybe i misunderstand the code, but i'd appreciate it if you give me some detail explanation, thx!

Subject. I don't see any close or cleanup functions for client side of library. Is it as intended?

this would make it easier for packager.

The function uint32_to_le/uint32_to_le shall convert an integer value to little endian or from little endian. But it seems that the endianess check seems a bit weak. When cross compiled for a big endian target, the check mentioned above has not detected the targets big endianess.

When I currently include protobuf-c-rpc.h, I'm forced to externally bracket it with:

#ifdef __cplusplus
extern "C" {
#endif
#include <protobuf-c-rpc/protobuf-c-rpc.h>
#ifdef __cplusplus
}
#endif

This could be remedied by adding something like this before the #includes in protobuf-c-rpc.h:

#if defined(__cplusplus) && !defined(PROTOBUF_C__BEGIN_DECLS)
# define PROTOBUF_C__BEGIN_DECLS	extern "C" {
# define PROTOBUF_C__END_DECLS		}
#else
# define PROTOBUF_C__BEGIN_DECLS
# define PROTOBUF_C__END_DECLS
#endif

Greetings!
I’m trying to implement a gRPC server based on the examples you have provided.
As for the client, I’m using a Go client, setting it up like this:

func setupClient(target string) (pb.Rpc1Client, error) {
  conn, err := grpc.Dial(target, grpc.WithTransportCredentials(insecure.NewCredentials()))
  if err != nil {
    return nil, err
  }
  return pb.NewRpc1Client(conn), nil
}

Unfortunately, when trying to send a request to the server I get an error. Client side:

2023/08/03 05:37:01 INFO: [transport] transport: loopyWriter.run returning. connection error: desc = "transport is closing"
2023/08/03 05:37:01 WARNING: [core] grpc: addrConn.createTransport failed to connect to {192.168.98.13:7777 192.168.98.13:7777 <nil> <nil> 0 <nil>}: failed to receive server preface within timeout

Server side: PROTOBUF_C_RPC_PROTOCOL_STATUS_INCOMPLETE_BUFFER

Successful request, C client:

Failed exchange, Go client:

It looks like the Go client attempts to connect using HTTP/2 as transport whereas the server does not support it.
Could you please help me solve this problem: is there a way I can tune the server to be compatible with the Go client or it is not possible at all?