Update Doku aus Driversourcen
Change-Id: I455f0813b970151089b3dc1b8d9407eea323cdd1
diff --git a/doc/concepts/mccp b/doc/concepts/mccp
index f3e31fb..5cb605d 100644
--- a/doc/concepts/mccp
+++ b/doc/concepts/mccp
@@ -2,14 +2,14 @@
mccp - The Mud Client Compression Protocol
DESCRIPTION
- Informations and code taken from the MCCP Homepage
+ Information and code taken from the MCCP Homepage
http://www.randomly.org/projects/MCCP/
MCCP is implemented as a Telnet option [RFC854, RFC855]. The server
and client negotiate the use of MCCP as they would any other telnet
option. Once agreement has been reached on the use of the option,
option subnegotiation is used to determine acceptable compression
- methods to use, and to indicate the start of a compressed data stream.
+ methods to use, and to indicate the start of a compressed data stream.
If the driver is compiled with MCCP Support there is a
define __MCCP__.
@@ -24,7 +24,7 @@
Notice: when the client uses compressions all binary_message calls
are executed with flag=3. This is because writing to the
socket would disturb zlib stream.
-
+
mccp-efuns:
start_mccp_compress(int telopt) (only needed with H_NOECHO)
@@ -32,7 +32,7 @@
query_mccp(object player)
query_mccp_stats(object player)
- Initiating MCCP without H_NOECHO hook:
+ Initiating MCCP without H_NOECHO hook:
if(!query_mccp()){
binary_message(({ IAC, WILL, TELOPT_COMPRESS2 }),1)
@@ -41,42 +41,43 @@
the driver will parse the clients answers and start compression.
(The connection might already be compressed, because although the
- documentation says clients should not negotiate from themselfes,
+ documentation says clients should not negotiate from themselves,
zmud e.g. does.)
You can start and stop compression manually by efuns
when you are sure client supports compression :)
- Initiating MCCP compression with H_NOECHO hook:
+ Initiating MCCP compression with H_NOECHO hook:
If your mudlib uses the H_NOECHO driver-hook you decided to do
all the negotiation by yourself:
Server Commands
- IAC WILL COMPRESS indicates the sender supports version 1 of the
- protocol, and is willing to compress data it sends.
+ IAC WILL COMPRESS indicates the sender supports version 1 of the
+ protocol, and is willing to compress data it sends.
IAC WILL COMPRESS2 indicates the sender supports version 2, and is
- willing to compress data it sends.
+ willing to compress data it sends.
- IAC WONT COMPRESS indicates the sender refuses to compress data using
- version 1.
+ IAC WONT COMPRESS indicates the sender refuses to compress data using
+ version 1.
IAC WONT COMPRESS2 indicates the sender refuses to compress data
- using version 2.
+ using version 2.
Client Commands
- IAC DO COMPRESS indicates the sender supports version 1 of the
- protocol, and is willing to decompress data received.
+ IAC DO COMPRESS indicates the sender supports version 1 of the
+ protocol, and is willing to decompress data
+ received.
- IAC DO COMPRESS2 indicates the sender supports version 2 or above,
- and is willing to decompress data received.
+ IAC DO COMPRESS2 indicates the sender supports version 2 or above,
+ and is willing to decompress data received.
- IAC DONT COMPRESS indicates the sender refuses to support version 1.
- If compression was previously negotiated and is
- currently being used, the server should terminate
- compression.
+ IAC DONT COMPRESS indicates the sender refuses to support version 1.
+ If compression was previously negotiated and is
+ currently being used, the server should terminate
+ compression.
IAC DONT COMPRESS2 indicates the sender refuses to support version 2.
If compression was previously negotiated and is
@@ -96,5 +97,4 @@
SEE ALSO
start_mccp_compress(E), end_mccp_compress(E), query_mccp(E),
- query_mccp_stats(object player)
-
+ query_mccp_stats(E)