Correct typo

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3113 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2005-12-02 22:56:59 +00:00
parent 77cadb064b
commit f0c28326a8

View File

@ -21,7 +21,7 @@
</author> </author>
</authorgroup> </authorgroup>
<pubdate>2005-11-26</pubdate> <pubdate>2005-12-02</pubdate>
<copyright> <copyright>
<year>2001-2004</year> <year>2001-2004</year>
@ -110,12 +110,12 @@
end of that connection. This is mostly useful if you don't have access to end of that connection. This is mostly useful if you don't have access to
traffic control on the other side and if this other side has a faster traffic control on the other side and if this other side has a faster
network connection than you do (the line speed between the systems is the network connection than you do (the line speed between the systems is the
bottleneck, e.g. a DSL or Cable Modem connection to you provider's router, bottleneck, e.g. a DSL or Cable Modem connection to your provider's
the router itself is normally connected to a much faster backbone). So, if router, the router itself is normally connected to a much faster
you drop packets that are coming in too fast, the underlying protocol backbone). So, if you drop packets that are coming in too fast, the
might recognize this and slow down the connection. TCP has a builtin underlying protocol might recognize this and slow down the connection. TCP
mechanism for this, UDP has not (but the protocol over UDP might recognize has a builtin mechanism for this, UDP has not (but the protocol over UDP
it , if there is any).</para> might recognize it , if there is any).</para>
<para>The reason why queing is bad in these cases is, that you might have <para>The reason why queing is bad in these cases is, that you might have
packets which need to be priorized over others, e.g. VoIP or ssh. For this packets which need to be priorized over others, e.g. VoIP or ssh. For this