manual: s/pipe/socket in the section on AFS.

The AFS process passes an open file descriptor to the server process,
which is only possible with sockets but not with pipes.

diff --git a/web/manual.md b/web/manual.md
index b33fd20a2d5b228c9dcc6efedc80db1b1973ca94..4c7d3eb499462c49905f372033e534ef9d1bb316 100644 (file)
--- a/web/manual.md
+++ b/web/manual.md
@@ -717,8 +717,8 @@ The AFS process
 
 On startup, para_server forks to create the AFS process which opens
 the database tables. The AFS process accepts incoming connections
-which arrive either on a pipe which is shared with para_server,
-or on the local socket it is listening on. The setup is as follows.
+which arrive either on a socket shared with para_server or on the
+local socket. The setup is as follows.
 
                  .___________________.  .______________.
                  |                   |  |              |
@@ -751,9 +751,8 @@ or on the local socket it is listening on. The setup is as follows.
                               |_____________|
 
 The virtual streaming system, which is part of the server process,
-communicates with the AFS process via pipes and shared memory. When
-the current audio file changes, it sends a notification through the
-shared pipe. The AFS process queries the database to determine the
+sends a notification to the shared socket whenever the current audio
+file changes. The AFS process queries the database to determine the
 next audio file, opens it, verifies that it has not been changed since
 it was added to the database and passes the open file descriptor back
 to the virtual streaming system, along with audio file meta-data such