Update internals chapter with regards to ranch_conns_sup

1 files changed, 13 insertions, 19 deletions

diff --git a/guide/internals.md b/guide/internals.md
index 35fd39b..03977c1 100644
--- a/guide/internals.md
+++ b/guide/internals.md
@@ -20,25 +20,19 @@ Like all OTP applications, Ranch has a top supervisor. It is responsible
 for supervising the `ranch_server` process and all the listeners that
 will be started.
 
-The `ranch_server` gen_server is the central process keeping track of the
-listeners, the acceptors and the connection processes. It does so through
-the use of a public ets table called `ranch_server` too. This allows
-some operations to be sequential by going through the gen_server, while
-others just query the ets table directly, ensuring there is no bottleneck
-for the most common operations.
-
-Because the most common operation is keeping track of the number of
-connections currently being used for each listener, the ets table
-has `write_concurrency` enabled, allowing us to perform all these
-operations concurrently using `ets:update_counter/3`. To read the number
-of connections we simply increment the counter by 0, which allows us
-to stay in a write context and still receive the counter's value.
-
-For increased fault tolerance, the owner of the ets table is
-`ranch_sup` and not `ranch_server` as you could expect. This way,
-if the `ranch_server` gen_server fails, it doesn't lose any information
-and the restarted process can continue as if nothing happened. Note that
-this usage is not recommended by OTP.
+The `ranch_server` gen_server is a central process keeping track of the
+listeners and their acceptors. It does so through the use of a public ets
+table called `ranch_server`. The table is owned by the top supervisor
+to improve fault tolerance. This way if the `ranch_server` gen_server
+fails, it doesn't lose any information and the restarted process can
+continue as if nothing happened.
+
+Ranch uses a custom supervisor for managing connections. This supervisor
+keeps track of the number of connections and handles connection limits
+directly. While it is heavily optimized to perform the task of creating
+connection processes for accepted connections, it is still following the
+OTP principles and the usual `sys` and `supervisor` calls will work on
+it as expected.
 
 Listeners are grouped into the `ranch_listener_sup` supervisor and
 consist of three kinds of processes: the listener gen_server, the