Add transport_opt() pool_size

Transport processes are started by diameter one at a time. In the
listening case, a transport process accepts a connection, tells the
peer_fsm process, which tells its watchdog process, which tells its
service process, which then starts a new watchdog, which starts a new
peer_fsm, which starts a new transport process, which (finally) goes
about accepting another connection. In other words, not particularly
aggressive in accepting new connections. This behaviour doesn't do
particularly well with a large number of concurrent connections: with
TCP and 250 connecting peers we see connections being refused.

This commit adds the possibilty of configuring a pool of accepting
processes, by way of a new transport option, pool_size. Instead of
diameter:add_transport/2 starting just a single process, it now starts
the configured number, so that instead of a single process waiting for a
connection there's now a pool.

The option is even available for connecting processes, which provides an
alternate to adding multiple transports when multiple connections to the
same peer are required. In practice this also means configuring
{restrict_connections, false}: this is not implicit.

For backwards compatibility, the form of
diameter:service_info(_,transport) differs in the connecting case,
depending on whether or not pool_size is configured.

Note that transport processes for the same transport_ref() can be
started concurrently when pool_size > 1. This places additional
requirements on diameter_{tcp,sctp}, that will be dealt with in a
subsequent commit.

1 files changed, 22 insertions, 1 deletions

diff --git a/lib/diameter/doc/src/diameter.xml b/lib/diameter/doc/src/diameter.xml
index 00b54ffbc4..538011b789 100644
--- a/lib/diameter/doc/src/diameter.xml
+++ b/lib/diameter/doc/src/diameter.xml
@@ -21,7 +21,7 @@
 
 <copyright>
 <year>2011</year>
-<year>2014</year>
+<year>2015</year>
 <holder>Ericsson AB. All Rights Reserved.</holder>
 </copyright>
 <legalnotice>
@@ -1188,6 +1188,19 @@ See &man_tcp; for the behaviour of that module.</p>
 </note>
 </item>
 
+<tag><c>{pool_size, pos_integer()}</c></tag>
+<item>
+<p>
+Number of transport processes to start.
+For a listening transport, defines the size of the pool of accepting
+transport processes, a larger number being desirable for processing
+multiple concurrent peer connection attempts.
+For a connecting transport, the &service_opt;
+<c>restrict_connections</c> must also be configured on the service in
+question to allow multiple connections to the same peer.</p>
+
+</item>
+
 <marker id="spawn_opt"/>
 <tag><c>{spawn_opt, [term()]}</c></tag>
 <item>
@@ -1737,6 +1750,14 @@ connection might look as follows.</p>
 The information presented here is as in the <c>connect</c> case except
 that the client connections are grouped under an <c>accept</c> tuple.</p>
 
+<p>
+Whether or not the &transport_opt; <c>pool_size</c> affects the format
+of the listing in the case of a connecting transport, since a value
+greater than 1 implies multiple transport processes for the same
+<c>&transport_ref;</c>, as in the listening case.
+The format in this case is similar to the listening case, with a
+<c>pool</c> tuple in place of an <c>accept</c> tuple.</p>
+
 </item>
 
 <tag><c>connections</c></tag>