tree: cb6fa50c257a7c4879f185e398275ddf5ac770e4 [path history] [tgz]
  1. channel_connectivity.c
  2. client_channel.c
  3. client_channel.h
  4. client_channel_factory.c
  5. client_channel_factory.h
  6. client_config.c
  7. client_config.h
  8. client_config_plugin.c
  9. connector.c
  10. connector.h
  11. default_initial_connect_string.c
  12. initial_connect_string.c
  13. initial_connect_string.h
  14. lb_policy.c
  15. lb_policy.h
  16. lb_policy_factory.c
  17. lb_policy_factory.h
  18. lb_policy_registry.c
  19. lb_policy_registry.h
  20. parse_address.c
  21. parse_address.h
  22. README.md
  23. resolver.c
  24. resolver.h
  25. resolver_factory.c
  26. resolver_factory.h
  27. resolver_registry.c
  28. resolver_registry.h
  29. subchannel.c
  30. subchannel.h
  31. subchannel_call_holder.c
  32. subchannel_call_holder.h
  33. subchannel_factory.c
  34. subchannel_factory.h
  35. subchannel_index.c
  36. subchannel_index.h
  37. uri_parser.c
  38. uri_parser.h
src/core/ext/client_config/README.md

Client Configuration Support for GRPC

This library provides high level configuration machinery to construct client channels and load balance between them.

Each grpc_channel is created with a grpc_resolver. It is the resolver's duty to resolve a name into configuration data for the channel. Such configuration data might include:

  • a list of (ip, port) addresses to connect to
  • a load balancing policy to decide which server to send a request to
  • a set of filters to mutate outgoing requests (say, by adding metadata)

The resolver provides this data as a stream of grpc_client_config objects to the channel. We represent configuration as a stream so that it can be changed by the resolver during execution, by reacting to external events (such as a new configuration file being pushed to some store).

Load Balancing

Load balancing configuration is provided by a grpc_lb_policy object, stored as part of grpc_client_config.

The primary job of the load balancing policies is to pick a target server given only the initial metadata for a request. It does this by providing a grpc_subchannel object to the owning channel.

Sub-Channels

A sub-channel provides a connection to a server for a client channel. It has a connectivity state like a regular channel, and so can be connected or disconnected. This connectivity state can be used to inform load balancing decisions (for example, by avoiding disconnected backends).

Configured sub-channels are fully setup to participate in the grpc data plane. Their behavior is specified by a set of grpc channel filters defined at their construction. To customize this behavior, resolvers build grpc_client_channel_factory objects, which use the decorator pattern to customize construction arguments for concrete grpc_subchannel instances.

Naming for GRPC

Names in GRPC are represented by a URI (as defined in RFC 3986).

The following schemes are currently supported:

dns:///host:port - dns schemes are currently supported so long as authority is empty (authority based dns resolution is expected in a future release)

unix:path - the unix scheme is used to create and connect to unix domain sockets - the authority must be empty, and the path represents the absolute or relative path to the desired socket

ipv4:host:port - a pre-resolved ipv4 dotted decimal address/port combination

ipv6:[host]:port - a pre-resolved ipv6 address/port combination