I'm afraid in my case a channel created from fd behaves a different way. Just to mention I use grpc version tagged v1.19.1, maybe this was modified later.
A simple test I did is based on helloworld example( https://github.com/grpc/grpc/tree/v1.19.1/examples/cpp/helloworld/{greeter_client.cc,greeter_server.cc} ): - original version I periodically (1 second) send a SayHello message from client to server, the server responds. After a few messages I stop the server binary. Then client prints on output: Greeter received: RPC failed > 14: channel is in state TRANSIENT_FAILURE > But when server is started again, the client is able to reconnect and contintues to send and receive SayHello messages. >From strace logs it looks that grpc framework on client side saved the server information passed to grpc::CreateChannel(). When the connection is broken, the grpc framework calls shutdown() and close() on fd used(sendmsg() and recvmsg() were called on that fd). During the server shutdown, the client periodically creates a new socket, tries to connect and eventually closes the fd. But when the server is back again, the connect is successfull and communication is back again. - fd-based version In my main application I use TIPC and Unix Domain sockets, but for this test an AF_INET socket is used. Scenario is the same, but after a server relaunch, the client cannot reconnect. From strace it looks like the client hasn't saved information about the passed fd (no call to getsockname()). Here is how I initialize client and server based on fd (return codes are omitted intentionally (no errors), other parts of the code also, there is only one client): server side: int server_fd; struct sockaddr_in address; server_fd = socket(AF_INET, SOCK_STREAM, 0); address.sin_family = AF_INET; address.sin_addr.s_addr = INADDR_ANY; address.sin_port = htons(PORT); bind(server_fd, (struct sockaddr *)&address, sizeof(address); listen(server_fd, 0); int flags = fcntl(server_fd, F_GETFL); fcntl(server_fd, F_SETFL, flags | O_NONBLOCK); GreeterServiceImpl service; ServerBuilder builder; builder.RegisterService(&service); std::unique_ptr<Server> server(builder.BuildAndStart()); int client_fd = -1; while(1)*{* client_fd = accept(server_fd, nullptr, nullptr); if (client_fd == -1 ) continue; flags = fcntl(client_fd, F_GETFL); fcntl(client_fd, F_SETFL, flags | O_NONBLOCK); ::grpc::AddInsecureChannelFromFd(server.get(), client_fd); } client side: int client_fd; struct sockaddr_in serv_addr; client_fd = socket(AF_INET, SOCK_STREAM, 0); serv_addr.sin_family = AF_INET; serv_addr.sin_port = htons(PORT); inet_pton(AF_INET, "127.0.0.1", &serv_addr.sin_addr); connect(client_fd, (struct sockaddr *)&serv_addr, sizeof(serv_addr)); int flags = fcntl(client_fd, F_GETFL); fcntl(client_fd, F_SETFL, flags | O_NONBLOCK); auto channel = grpc::CreateInsecureChannelFromFd(Greeter::service_full_name(), client_fd); GreeterClient greeter(channel); śr., 6 maj 2020 o 19:36 'Mark D. Roth' via grpc.io <[email protected]> napisał(a): > gRPC takes ownership of the fd when you pass it to > CreateInsecureChannelFromFd(), so you don't need to shut it down or close > it. > > On Tuesday, May 5, 2020 at 4:33:23 AM UTC-7 [email protected] wrote: > >> Hi, >> I'm creating a grpc channel for the grpc client using >> function CreateInsecureChannelFromFd() and giving the file descriptor to >> it. >> Should I handle the connection for the given file descriptor afterwards >> in application or is it handled in grpc framework? >> >> For example on application side when messages are not delivered I >> reconnect using shutdown() or close() etc. >> Is it necessary? From strace log I found multiple calls to close() on the >> same fd like some are called by application and some by grpc framework. >> >> Sorry, if something is written badly - my first post here. >> >> -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/9da96e2f-5547-4bf0-a21d-e64432a67cd9%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/9da96e2f-5547-4bf0-a21d-e64432a67cd9%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAP74dWotJ2GVj%2B0EK1409-ObFxZOVGOY%2BzLW%3DWtkeKTpyrBXCA%40mail.gmail.com.
