gsoc 2018 - "Make channel-connectivity-watching cancellable" insights requested

[kaustubh.k...@gmail.com]

Hi gRPC community,

My name is Kaustubh and I am a graduate student at Texas A&M University. I have a background in Distributed systems and have enjoyed using gRPC and Protbuf in my project. This summer I look forward to contribute to the current idea in gRPC of "Make channel-connectivity-watching cancellable".

I have read about the issue on github but I believe I need more insights to create a thorough proposal for the same. Will appreciate any documentation or code repos links which can be useful for coming up with a plan for implementation of this idea.

Hope to hear soon !

Regards,
Kaustubh Kapileshwar

[Nathaniel Manista]

On Tue, Mar 13, 2018 at 1:27 PM, <kaustubh.k...@gmail.com> wrote:

My name is Kaustubh and I am a graduate student at Texas A&M University. I have a background in Distributed systems and have enjoyed using gRPC and Protbuf in my project. This summer I look forward to contribute to the current idea in gRPC of "Make channel-connectivity-watching cancellable".

Pleased to meet you!

I have read about the issue on github but I believe I need more insights to create a thorough proposal for the same. Will appreciate any documentation or code repos links which can be useful for coming up with a plan for implementation of this idea.

One good place to start would be the grpc.h file - this is what specifies the API between gRPC Core and the higher-level language-specific wrappings, and channel connectivity is specified as part of that API. Then I think the next place to go would be into the gRPC Core implementation to see how connectivity is implemented. Beyond that there may be something to learn about why it was implemented the way it was in source control history and comments in the code, but... there just as likely may not be anything there. It's worth noting that over the course of its history the bug was closed and reopened. Beyond that there may be esoteric philosophy that doesn't much affect the code but is worth tossing around one's mind: what does it mean to be "connected" in the context of packet-switched networking? Does the channel connectivity subAPI define good concepts that can be used without caveat or do they have to be interpreted by applications? Should the API have been structured differently? (These questions are larger than the task of making channel-connectivity-watching cancellable, but they are the context in which the task resides.)

-Nathaniel