SERVER-48755 added info on legacy networking

1 files changed, 9 insertions, 2 deletions

diff --git a/docs/egress_networking.md b/docs/egress_networking.md
index 2d9376b8136..5cf9e3f96ba 100644
--- a/docs/egress_networking.md
+++ b/docs/egress_networking.md
@@ -18,7 +18,11 @@ The `ConnectionPool::ConnectionInterface` is responsible for handling the connec
 
 Client-side outbound communication in egress networking is primarily handled by the [AsyncDBClient class][async_client_h]. The async client is responsible for initializing a connection to a particular host as well as initializing the [wire protocol][wire_protocol] for client-server communication, after which remote requests can be sent by the client and corresponding remote responses from a database can subsequently be received. In setting up the wire protocol, the async client sends an [isMaster][is_master] request to the server and parses the server's isMaster response to ensure that the status of the connection is OK. An initial isMaster request is constructed in the legacy OP_QUERY protocol, so that clients can still communicate with servers that may not support other protocols. The async client also supports client authentication functionality (i.e. authenticating a user's credentials, client host, remote host, etc.). 
 
-The scheduling of requests is managed by the [task executor][task_executor_h], which maintains the notion of **events** and **callbacks**. Callbacks represent work (e.g. remote requests) that is to be executed by the executor, and are scheduled by client threads as well as other callbacks. There are several variations of work scheduling methods, which include: immediate scheduling, scheduling no earlier than a specified time, and scheduling iff a specified event has been signalled. These methods return a handle that can be used while the executor is still in scope for either waiting on or cancelling the scheduled callback in question. If a scheduled callback is cancelled, it remains on the work queue and is technically still run, but is labeled as having been 'cancelled' beforehand. Once a given callback/request is scheduled, the task executor is then able to execute such requests via a [network interface][network_interface_h]. The network interface, connected to a particular host/server, begins the asynchronous execution of commands specified via a request bundled in the aforementioned callback handle. The interface is capable of blocking threads until its associated task executor has work that needs to be performed, and is likewise able to return from an idle state when it receives a signal that the executor has new work to process.
+The scheduling of requests is managed by the [task executor][task_executor_h], which maintains the notion of **events** and **callbacks**. Callbacks represent work (e.g. remote requests) that is to be executed by the executor, and are scheduled by client threads as well as other callbacks. There are several variations of work scheduling methods, which include: immediate scheduling, scheduling no earlier than a specified time, and scheduling iff a specified event has been signalled. These methods return a handle that can be used while the executor is still in scope for either waiting on or cancelling the scheduled callback in question. If a scheduled callback is cancelled, it remains on the work queue and is technically still run, but is labeled as having been 'cancelled' beforehand. Once a given callback/request is scheduled, the task executor is then able to execute such requests via a [network interface][network_interface_h]. The network interface, connected to a particular host/server, begins the asynchronous execution of commands specified via a request bundled in the aforementioned callback handle. The interface is capable of blocking threads until its associated task executor has work that needs to be performed, and is likewise able to return from an idle state when it receives a signal that the executor has new work to process. 
+
+Client-side legacy networking draws upon the `DBClientBase` class, of which there are multiple subclasses residing in the `src/mongo/client` folder. The [replica set DBClient][dbclient_rs_h] discerns which one of multiple servers in a replica set is the primary/master at construction time, and establishes a connection (using the `DBClientConnection` wrapper class, also extended from `DBClientBase`) with the replica set via the primary/master. In cases where the primary/master server is unresponsive within a specified time range, the RS DBClient will automatically attempt to establish a secondary/slave server as the new primary/master (see [automatic failover][automatic_failover]).
+
+**See also:** [Internal Ingress Networking][ingress_networking]
 
 [remote_command_request_h]: ../src/mongo/executor/remote_command_request.h
 [remote_command_response_h]: ../src/mongo/executor/remote_command_response.h
@@ -29,4 +33,7 @@ The scheduling of requests is managed by the [task executor][task_executor_h], w
 [is_master]: https://docs.mongodb.com/manual/reference/command/isMaster/
 [wire_protocol]: https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/
 [task_executor_h]: ../src/mongo/executor/task_executor.h
-[network_interface_h]: ../src/mongo/executor/network_interface.h
\ No newline at end of file
+[network_interface_h]: ../src/mongo/executor/network_interface.h
+[dbclient_rs_h]: ../src/mongo/client/dbclient_rs.h
+[automatic_failover]: https://docs.mongodb.com/manual/replication/#automatic-failover
+[ingress_networking]: ../src/mongo/transport/README.md
\ No newline at end of file