aboutsummaryrefslogtreecommitdiffhomepage
path: root/doc/naming.md
diff options
context:
space:
mode:
authorGravatar Abhishek Kumar <abhikumar@google.com>2015-07-21 10:00:36 -0700
committerGravatar Abhishek Kumar <abhikumar@google.com>2015-07-21 10:00:36 -0700
commit2d8eeb416ba465c169ce763a0b46f2c7914deaed (patch)
treea7c994babd1d5e61fbe1a2fded7abfc98a36b357 /doc/naming.md
parent8c8ecd8da1b81809876105aba2dd48b10e6ba63a (diff)
Formatting fixes
Added some formatting fixes .
Diffstat (limited to 'doc/naming.md')
-rw-r--r--doc/naming.md35
1 files changed, 17 insertions, 18 deletions
diff --git a/doc/naming.md b/doc/naming.md
index e9101db991..9294529ea5 100644
--- a/doc/naming.md
+++ b/doc/naming.md
@@ -1,51 +1,50 @@
-gRPC Naming and Discovery Support
+#gRPC Naming and Discovery Support
-Hongwei Yang, Craig Tiller, Eric Anderson, Abhishek Kumar
-
-# Overview
+## Overview
gRPC supports DNS as the default name-system. A number of alternative name-systems are used in various deployments. We propose an API that is general enough to support a range of name-systems and the corresponding syntax for names. The gRPC client library in various languages will provide a plugin mechanism so resolvers for different name-systems can be plugged in.
-# Detailed Proposal
+## Detailed Proposal
A fully qualified, self contained name used for gRPC channel construction uses the syntax:
-scheme://authority/endpoint_name
+```scheme://authority/endpoint_name
+```
Here, scheme indicates the name-system to be used. Example schemes to be supported include:
-* dns
+* `dns`
-* zookeeper
+* `zookeeper`
-* etcd
+* `etcd`
Authority indicates some scheme-specific bootstrap information, e.g., for DNS, the authority may include the IP[:port] of the DNS server to use. Often, a DNS name may used as the authority, since the ability to resolve DNS names is already built into all gRPC client libraries.
Finally, the endpoint_name indicates a concrete name to be looked up in a given name-system identified by the scheme and the authority. The syntax of endpoint name is dictated by the scheme in use.
-## Plugins
+### Plugins
The gRPC client library will switch on the scheme to pick the right resolver plugin and pass it the fully qualified name string.
Resolvers should be able to contact the authority and get a resolution that they return back to the gRPC client library. The returned contents include a list of IP:port, an optional config and optional auth config data to be used for channel authentication. The plugin API allows the resolvers to continuously watch an endpoint_name and return updated resolutions as needed.
-# Zookeeper
+## Zookeeper
-Apache [ZooKeeper](https://zookeeper.apache.org/) is a popular solution for building name-systems. Curator is a service discovery system built on to of ZooKeeper. We propose to organize names hierarchically as /path/service/instance similar to Apache Curator.
+Apache [ZooKeeper](https://zookeeper.apache.org/) is a popular solution for building name-systems. Curator is a service discovery system built on to of ZooKeeper. We propose to organize names hierarchically as `/path/service/instance similar` to Apache Curator.
A fully-qualified ZooKeeper name used to construct a gRPC channel will look as follows:
-zookeeper://host:port/path/service/instance
-
-Here zookeeper is the scheme identifying the name-system. host:port identifies an authoritative name-server for this scheme (i.e., a Zookeeper server). The host can be an IP address or a DNS name.
-Finally /path/service/instance is the Zookeeper name to be resolved.
+```zookeeper://host:port/path/service/instance
+```
+Here `zookeeper` is the scheme identifying the name-system. `host:port` identifies an authoritative name-server for this scheme (i.e., a Zookeeper server). The host can be an IP address or a DNS name.
+Finally `/path/service/instance` is the Zookeeper name to be resolved.
## Service Registration
Service providers can register their services in Zookeeper by using a Zookeeper client.
-Each service is a zookeeper node, and each instance is a child node of the corresponding service. For example, a MySQL service may have multiple instances, /mysql/1, /mysql/2, /mysql/3. The name of the service or instance, as well as an optional path is specified by the service provider.
+Each service is a zookeeper node, and each instance is a child node of the corresponding service. For example, a MySQL service may have multiple instances, `/mysql/1`, `/mysql/2`, `/mysql/3`. The name of the service or instance, as well as an optional path is specified by the service provider.
-The data in service nodes is empty. Each instance node stores its address in the format of host:port, where host can be either hostname or IP address.
+The data in service nodes is empty. Each instance node stores its address in the format of `host:port`, where host can be either hostname or IP address.