This avoids a regression for issues like #334 where high speed
repeated connections eventually run the HTTP client out of
sockets because all of theirs end up in time_wait.
Maybe the trade-off here is suboptimal, but if both choices will
fail then we prefer fewer changes until the root cause is solved.
strUsage+=" -rpcport=<port> "+strprintf(_("Listen for JSON-RPC connections on <port> (default: %u or testnet: %u)"),8332,18332)+"\n";
strUsage+=" -rpcallowip=<ip> "+_("Allow JSON-RPC connections from specified source. Valid for <ip> are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24). This option can be specified multiple times")+"\n";
strUsage+=" -rpcthreads=<n> "+strprintf(_("Set the number of threads to service RPC calls (default: %d)"),4)+"\n";
strUsage+=" -rpckeepalive "+strprintf(_("RPC support for HTTP persistent connections (default: %d)"),0)+"\n";
strUsage+=" -rpckeepalive "+strprintf(_("RPC support for HTTP persistent connections (default: %d)"),1)+"\n";
strUsage+="\n"+_("RPC SSL options: (see the Bitcoin Wiki for SSL setup instructions)")+"\n";
strUsage+=" -rpcssl "+_("Use OpenSSL (https) for JSON-RPC connections")+"\n";