SERVER-48716 Completed doc, added links to files in docs/README.md

4 files changed, 91 insertions, 3 deletions

diff --git a/docs/command_dispatch.md b/docs/command_dispatch.md
new file mode 100644
index 00000000000..844fb0ffb8a
--- /dev/null
+++ b/docs/command_dispatch.md
@@ -0,0 +1,85 @@
+# Command Dispatch
+
+Command dispatch refers to the general process by which client requests are
+taken from the network, parsed, sanitized, then finally run on databases.
+
+## Service Entry Points
+
+[Service entry points][service_entry_point_h] fulfill the transition from the
+transport layer into command implementations. For each incoming connection
+from a client (in the form of a [session][session_h] object), a new dedicated
+thread is spawned then detached, and is also assigned a new [service state
+machine][service_state_machine_h], responsible for maintaining the state of a
+single client connection during its lifetime. Central to the entry point is the
+`handleRequest()` function, which manages the server-side logic of processing
+requests and returns a response message indicating the result of the
+corresponding request message. This function is currently implemented by several
+subclasses of the parent `ServiceEntryPoint` in order to account for the
+differences in processing requests between *mongod* and *mongos* -- these
+distinctions are reflected in the `ServiceEntryPointMongos` and
+`ServiceEntryPointMongod` subclasses (see [here][service_entry_point_mongos_h]
+and [here][service_entry_point_mongod_h]). One such distinction is the *mongod*
+entry point's use of the `ServiceEntryPointCommon::Hooks` interface, which
+provides greater flexibility in modifying the entry point's behavior. This
+includes waiting on a read of a particular [read concern][read_concern] level to
+be completed, as well as determining whether a read concern can indeed by
+satisfied given the current state of the server. Similar functionality exists
+for [write concerns][write_concern] as well.
+
+## Strategy
+
+One area in which the *mongos* entry point differs from its *mongod* counterpart
+is in its usage of the [Strategy class][strategy_h]. `Strategy` operates as a
+legacy interface for processing client read, write, and command requests; there
+is a near 1-to-1 mapping between its constituent functions and request types
+(e.g. `writeOp()` for handling write operation requests, `getMore()` for a
+getMore request, etc.). These functions comprise the backbone of the *mongos*
+entry point's `handleRequest()` -- that is to say, when a valid request is
+received, it is sieved and ultimately passed along to the appropriate Strategy
+class member function. The significance of using the Strategy class specifically
+with the *mongos* entry point is that it [facilitates query routing to
+shards][mongos_router] in *addition* to running queries against targeted
+databases (see [s/transaction_router.h][transaction_router_h] for finer
+details).
+
+## Commands
+
+The [Command class][commands_h] serves as a means of cataloging a server command
+as well as ascribing various attributes and behaviors to commands via the [type
+system][template_method_pattern], that will likely be used during the lifespan
+of a particular server. Construction of a Command should only occur during
+server startup. When a new Command is constructed, that Command is stored in a
+global `CommandRegistry` object for future reference. There are two kinds of
+Command subclasses: `BasicCommand` and `TypedCommand`. 
+
+A major distinction between the two is in their implementation of the `parse()`
+member function. `parse()` takes in a request and returns a handle to a single
+invocation of a particular Command (represented by a `CommandInvocation`), that
+can then be used to run the Command. The `BasicCommand::parse()` is a naive
+implementation that merely forwards incoming requests to the Invocation and
+makes sure that the Command does not support document sequences. The
+implementation of `TypedCommand::parse()`, on the other hand, varies depending
+on the Request type parameter the Command takes in. Since the `TypedCommand`
+accepts requests generated by IDL, the parsing function associated with a usable
+Request type must allow it to be parsed as an IDL command. In handling requests,
+both the *mongos* and *mongod* entry points interact with the Command subclasses
+through the `CommandHelpers` struct in order to parse requests and ultimately
+run them as Commands.
+
+## See Also
+
+For details on transport internals, including ingress networking, see [this document][transport_internals].
+
+[service_entry_point_h]: ../src/mongo/transport/service_entry_point.h
+[session_h]: ../src/mongo/transport/session.h
+[service_state_machine_h]: ../src/mongo/transport/service_state_machine.h
+[service_entry_point_mongos_h]: ../src/mongo/s/service_entry_point_mongos.h
+[service_entry_point_mongod_h]: ../src/mongo/db/service_entry_point_mongod.h
+[read_concern]: https://docs.mongodb.com/manual/reference/read-concern/
+[write_concern]: https://docs.mongodb.com/manual/reference/write-concern/
+[strategy_h]: ../src/mongo/s/commands/strategy.h
+[mongos_router]: https://docs.mongodb.com/manual/core/sharded-cluster-query-router/
+[transaction_router_h]: ../src/mongo/s/transaction_router.h
+[commands_h]: ../src/mongo/db/commands.h
+[template_method_pattern]: https://en.wikipedia.org/wiki/Template_method_pattern 
+[transport_internals]: ../src/mongo/transport/README.md
\ No newline at end of file
diff --git a/docs/index.md b/docs/index.md
index 12ec4595009..451eb5f682a 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -6,8 +6,10 @@ This is just some internal documentation.
 For the full MongoDB docs, please see [mongodb.org](http://www.mongodb.org/)
 
 * [Building MongoDB](building.md)
+* [Command Dispatch](command_dispatch.md)
+* [Egress Networking](egress_networking.md)
 * [Exception Architecture](exception_architecture.md)
 * [Memory Management](memory_management.md)
 * [Parsing Stack Traces](parsing_stack_traces.md)
 * [String Manipulation](string_manipulation.md)
-* [MongoDB Voluntary Product Accessibility Template® (VPAT™)](vpat.md)
+* [MongoDB Voluntary Product Accessibility Template® (VPAT™)](vpat.md)
\ No newline at end of file
diff --git a/src/mongo/db/service_entry_point_common.h b/src/mongo/db/service_entry_point_common.h
index c122963bd44..090cf302b48 100644
--- a/src/mongo/db/service_entry_point_common.h
+++ b/src/mongo/db/service_entry_point_common.h
@@ -49,7 +49,7 @@ extern FailPoint skipCheckingForNotMasterInCommandDispatch;
 
 /**
  * Helpers for writing ServiceEntryPointImpl implementations from a reusable core.
- * Implementations are ServiceEntryPointMongo and ServiceEntryPointEmbedded, which share
+ * Implementations are ServiceEntryPointMongod and ServiceEntryPointEmbedded, which share
  * most of their code, but vary in small details captured by the Hooks customization
  * interface.
  */
diff --git a/src/mongo/transport/README.md b/src/mongo/transport/README.md
index c49ec3123d9..4d356fab87c 100644
--- a/src/mongo/transport/README.md
+++ b/src/mongo/transport/README.md
@@ -37,7 +37,7 @@ The various builders supplied in the ReplyBuilderInterface can be appended toget
 This interface acts as a cursor to build a response message to be sent out back to the client.
 
 ## See Also
-For details on egress networking, see [this document][egress_networking].
+For details on egress networking, see [this document][egress_networking]. For details on command dispatch, see [this document][command_dispatch].
 
 [ServiceExecutor]: service_executor.h
 [ServiceStateMachine]: service_state_machine.h
@@ -46,3 +46,4 @@ For details on egress networking, see [this document][egress_networking].
 [ReplyBuilderInterface]: ../rpc/reply_builder_interface.h
 [DocSequenceBuilder]: ../rpc/op_msg.h
 [egress_networking]: ../../../docs/egress_networking.md
+[command_dispatch]: ../../../docs/command_dispatch.md
\ No newline at end of file