gRPC core Architecture

571 views
Skip to first unread message

Rajarshi Biswas

unread,
Apr 27, 2017, 2:03:58 PM4/27/17
to grpc.io
Hi good people, 

I am Rajarshi, a computer science graduate student at the Ohio State University. 

My next project involves working with gRPC, hence I am trying to understand the core code. I am especially interested to understand the communication layer. Also, the relation between completion queue, execution contexts, closure, pollset etc.  Basically the way I am trying to understand is by reading the code, reading the docs in Github, and seeing the debug print statements.  Do you guys recommend any specific document to understand the core architecture in detail ?

Thank you. 

Rajarshi 

Sree Kuchibhotla

unread,
Apr 27, 2017, 2:27:32 PM4/27/17
to Rajarshi Biswas, grpc.io
Hi Rajarshi,
if you are planning to use grpc and build something on top of it, I would recommend just starting with example programs: https://github.com/grpc/grpc/tree/master/examples/cpp

If you are planning to understand the internals and want to contribute,  unfortunately there is no doc that explains the overall architecture. You can browse the docs here https://github.com/grpc/grpc/tree/master/doc to see if they help.
(in either case, I do think working on the examples is a good start)

thanks,
Sree

--
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/42ec50f1-9dad-4288-9fbf-0a9243399ce7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rajarshi Biswas

unread,
Apr 27, 2017, 2:40:09 PM4/27/17
to Sree Kuchibhotla, grpc.io
Hello Sree, 

Thank you for your response. 

I am interested to learn about the internals. I have gone through the cpp example that you have pointed.
I have been setting different environment variables, to print the debug messages when running the greeter_client and greeter_server. Also, using GDB to understand the function calls. Although, GDB does not show the line numbers in the gRPC code and its a burden. I tried to build the gRPC library with -g flag, and without any optimization flag, but still no line number when using gdb. 

One thing I am struggling to understand is the epoll mechanism and how it is doing the appropriate callback in response to an event (Checked - https://github.com/grpc/grpc/blob/master/doc/epoll-polling-engine.md). GDB didn't help me to see the actual function calls in each step.  So, for example when the greeter_server is listening and a client request comes, I want to understand the exact code flow that is happening. Do you have any suggestion or (pointer to source) for this?

_Sincerely, Rajarshi 
--
Rajarshi Biswas
Citrix R&D
India

Sree Kuchibhotla

unread,
Apr 28, 2017, 6:54:33 PM4/28/17
to Rajarshi Biswas, grpc.io
Understood.

Not sure why gdb is not showing linenumbers to you.. but I build grpc library by setting the environment variable "CONFIG = dbg".   (Most of the time I am lazy and just have our test script do the build for me .. i.e do 
    $tools/run_tests/run_tests.py -lc -cdbg --build_only
    $ tools/run_tests/run_tests.py -lc++ -cdbg --build_only"

Now regarding understanding how the flow works, I can tell you what worked for my rampup :) (can't say it works for everyone). 

I would first look at the grpc-c core API (under include/grpc/grpc.h) which is a bit more basic  (C++ API wraps our grpc-c core api)
and then look at the following simple client and servers written to use the C-Core APIs (separately under two instances of gdb)
  $grpc/test/core/fling/server.c 
  $grpc/test/core/fling/client.c

Put breakpoints at the following places on both client and server (some of them are more interesting for client and some for server but it doesn't matter):
  // kicks off the chain of callbacks when the fds become readable/writable
    fd_become_readable
  fd_become_writable

  // This is the one that starts a "batch of operations in a call" and also sets up the appropriate callbacks to call
  call_start_batch
 
  // Callback that ends up getting called on the server side for an incoming rpc
  accept_stream

There are obviously a LOT more places to poke around but the above is a good start.

Good luck debugging
thanks
Sree


Rajarshi Biswas

unread,
Apr 29, 2017, 12:34:58 PM4/29/17
to Sree Kuchibhotla, grpc.io
Thanks Sree for the pointers. 

I have looked at the server.c and client.c and the code makes sense. Now, I am trying to understand what is actually happening in all the function calls, especially the completion queue logic - grpc_completion_queue_next). 
I will get back to you if I have (and for sure i will have ;) ) more questions. 

Thanks again!!

Rajarshi Biswas

unread,
May 10, 2017, 12:46:30 PM5/10/17
to Sree Kuchibhotla, grpc.io
Hello again Sree!

I have understood the broad architecture by using gdb (setting CONFIG=dbg helped) and reading the code. However, the whole pollset business is not still clear, I am trying to understand it. 
Could you please briefly tell me the difference between tcp_handle_write and tcp_write  and similarly tcp_handle_read and tcp_read? 

_Thanks , Rajarshi 


Reply all
Reply to author
Forward
0 new messages