how to get the grpc server fd

162 views
Skip to first unread message

Richard Chan

unread,
May 22, 2017, 11:49:35 PM5/22/17
to grpc.io
hi

i want to get grpc server fd, to polling the fd in my code.
is there any existing api to accomplish this ?

i only see make grpc from fd in server_posix.h 

Vijay Pai

unread,
May 25, 2017, 12:24:50 PM5/25/17
to grpc.io
We intentionally don't expose this interface in the current API as gRPC assumes that it has control over its FDs (even in the case of the server_from_fd and channel_from_fd functions that you described). Can you give us some more information about why you would want this or how you would use it?

Vivek M

unread,
Jun 2, 2017, 2:10:43 PM6/2/17
to grpc.io
Hi Vijay,

I was also wondering if there is a way to get this.

Lets say a client negotiates a HTTP/2 window size of 1 MB and the server sets its send window size to 1 MB. However if the underlying TCP socket's send buffer size is 64 KB (default value in FreeBSD), then I think only 64KB of data will be in flight. This may affect the throughput.

So if there is an option to get both the FD being used for an RPC() and the maximum window size that has been negotiated by the client, then we can try to increase the send buffer size (if our system permits) in the application.

Thanks,
Vivek

Vivek M

unread,
Jun 7, 2017, 3:43:17 AM6/7/17
to grpc.io
Hi Vijay,

Any thoughts on this?

Thanks,
Vivek

Noah Eisen

unread,
Jun 7, 2017, 10:55:35 AM6/7/17
to Vivek M, grpc.io
Hi Vivek,

Linking myself in since I have been working on c core flow control these days. Neither the grpc_fd objects, or the flow control parameters are made available to the user. This is a very conscious choice as we want to do all the fd bookkeeping ourselves and we want to optimize flow control ourselves. At the moment there are some known issues with flow control stalls under large message throughput situations, but that is under investigation.

In the mean time, you are welcome to do some experimentation, but it will have to happen through actually modifying the c core. Here are some interesting places you might look in the code based on this discussion and the on you had with Carl in a different thread:

target_write_size() is where we set a target size for the chunks actually hitting a write syscall. It's currently 1M

update_bdp() is where we update the connection's initial window to our estimate of the bdp. Note that a few lines later we update the max frame size to max(bdp and bandwidth per ms). I saw you mentioned this in the other thread.

Check those out to start. We can keep discussing in this thread if you want to start experimenting with performance. I am currently working on refactoring the flow control code to exist in one module with a clear interface.

Hope this helps!
Noah

--
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 grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/7d6f8bca-5a2e-44ba-aff6-6ea7eca25c93%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Vivek M

unread,
Jun 7, 2017, 1:39:28 PM6/7/17
to Noah Eisen, grpc.io
Hi Naoh,

Surely I can try these. Nice to hear that flow control is being worked out, what timeline/release can it be expected?

Before trying out your suggestions I would also like to know when there are lets say 10 streams (each 1 MB) per connection (10 MB is total connection window size as negotiated by client) and there is a server streaming call in progress, can all these 10 streams be potentially used by this one streaming call? I assume no as gRPC doesn't guarantee in-order delivery and hence only one stream will be in use per RPC call. Correct me if my understanding is wrong.

Thanks,
Vivek

Vijay Pai

unread,
Jun 7, 2017, 4:03:09 PM6/7/17
to grpc.io
1 stream == 1 RPC , whether it's a unary, single-sided streaming call, or bidirectional streaming call, and regardless of language. It's the basic assumption of the gRPC HTTP/2 wire format protocol.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
Reply all
Reply to author
Forward
0 new messages