Merge branch 'v5-devel'

Conflicts:
	configure.ac
	doc/manual.html
	plugins/imtcp/imtcp.c

4 files changed, 15 insertions, 18 deletions

diff --git a/doc/imtcp.html b/doc/imtcp.html
index 422bbd55..b0aaa3c1 100644
--- a/doc/imtcp.html
+++ b/doc/imtcp.html
@@ -57,6 +57,15 @@ instructs imtcp to emit a message if the remote peer closes a connection.<br>
 after loading imtcp, otherwise it may have no effect.</li>
 <li><b>$InputTCPServerRun</b> &lt;port&gt;<br>
 Starts a TCP server on selected port</li>
+<li><b>$InputTCPFlowControl</b> &lt;<b>on</b>/off&gt;<br>
+This setting specifies whether some message flow control shall be exercised on the
+related TCP input. If set to on, messages are handled as "light delayable", which means
+the sender is throttled a bit when the queue becomes near-full. This is done in order
+to preserve some queue space for inputs that can not throttle (like UDP), but it
+may have some undesired effect in some configurations. Still, we consider this as
+a useful setting and thus it is the default. To turn the handling off, simply
+configure that explicitely.
+</li>
 <li><b>$InputTCPMaxListeners</b> &lt;number&gt;<br>
 Sets the maximum number of listeners (server ports) supported. Default is 20. This must be set before the first $InputTCPServerRun directive.</li>
 <li><b>$InputTCPMaxSessions</b> &lt;number&gt;<br> Sets the maximum number of sessions supported. Default is 200. This must be set before the first $InputTCPServerRun directive</li>
diff --git a/doc/manual.html b/doc/manual.html
index 485f0e3f..45ad749d 100644
--- a/doc/manual.html
+++ b/doc/manual.html
@@ -111,5 +111,7 @@ any restriction as long as your license is GPLv3 compatible. If your license is
 you may even be still permitted to use rsyslog source code. However, then you need to look at the way
 <a href="licensing.html">rsyslog is licensed</a>.</p>
 <p>Feedback is always welcome, but if you have a support question, please do not
-mail Rainer directly (<a href="free_support.html">why not?</a>).
+mail Rainer directly (<a href="free_support.html">why not?</a>) - use the
+<a href="http://lists.adiscon.net/mailman/listinfo/rsyslog">rsyslogmailing list</a>
+or <a href="http://kb.monitorware.com/rsyslog-f40.html">rsyslog formum</a> instead.
 </body></html>
diff --git a/doc/rsyslog_conf_global.html b/doc/rsyslog_conf_global.html
index 7d121a4a..a5d69f1d 100644
--- a/doc/rsyslog_conf_global.html
+++ b/doc/rsyslog_conf_global.html
@@ -93,7 +93,7 @@ default 60000 (1 minute)]</li>
 <li>$ActionQueueWorkerThreadMinumumMessages &lt;number&gt;, default 100</li>
 <li><a href="rsconf1_actionresumeinterval.html">$ActionResumeInterval</a></li>
 <li>$ActionResumeRetryCount &lt;number&gt; [default 0, -1 means eternal]</li>
-<li>$ActionSendResendLastMsgOnReconn &lt;[on/<b>off</b>]&gt; specifies if the last message is to be resend when a connecition broken and has been reconnedcted. May increase reliability, but comes at the risk of message duplication.
+<li>$ActionSendResendLastMsgOnReconnect &lt;[on/<b>off</b>]&gt; specifies if the last message is to be resend when a connecition breaks and has been reconnected. May increase reliability, but comes at the risk of message duplication.
 <li>$ActionSendStreamDriver &lt;driver basename&gt; just like $DefaultNetstreamDriver, but for the specific action</li>
 <li>$ActionSendStreamDriverMode &lt;mode&gt;, default 0, mode to use with the stream driver (driver-specific)</li>
 <li>$ActionSendStreamDriverAuthMode &lt;mode&gt;,&nbsp; authentication mode to use with the stream driver. Note that this directive requires TLS
diff --git a/doc/rsyslog_tls.html b/doc/rsyslog_tls.html
index bb312c77..286660d2 100644
--- a/doc/rsyslog_tls.html
+++ b/doc/rsyslog_tls.html
@@ -162,25 +162,11 @@ similar "smart" command on the client. It should show up in the
 respective server log file. If you dig out your sniffer, you should see
 that the traffic on the wire is actually protected.</p>
 <h3>Limitations</h3>
-<p>The current implementation has a number of limitations. These
-are
-being worked on. Most importantly, neither the client nor the server
-are authenticated. So while the message transfer is encrypted, you can
-not be sure which peer you are talking to. Please note that this is a
-limitation found in most real-world SSL syslog systems. Of course, that
-is not an excuse for not yet providing this feature - but it tells you
-that it is acceptable and can be worked around by proper firewalling,
-ACLs and other organizational measures. Mutual authentication will be
-added shortly to rsyslog.</p>
-<p>Secondly, the plain tcp syslog listener
-can currently listen to a single port, in a single mode. So if you use
-a TLS-based listener, you can not run unencrypted syslog on the same
-instance at the same time. A work-around is to run a second rsyslogd
-instance. This limitation, too, is scheduled to be removed soon.</p>
 <p>The
 RELP transport can currently not be protected by TLS. A work-around is
 to use stunnel. TLS support for RELP will be added once plain TCP
-syslog has sufficiently matured.</p>
+syslog has sufficiently matured and there either is some time left to do this
+or we find a sponsor ;).</p>
 <h2>Certificates</h2>
 <p>In order to be really secure, certificates are needed. This is
 a short summary on how to generate the necessary certificates with