[Dcplusplus-commit] SF.net SVN: adc:[109] trunk

[<ul...@us...>]

Revision: 109
          http://sourceforge.net/p/adc/code/109
Author:   ullner
Date:     2013-06-30 13:47:09 +0000 (Sun, 30 Jun 2013)
Log Message:
-----------
Added ZLIB recommendation

Modified Paths:
--------------
    trunk/ADC-PRD.txt
    trunk/ADC-Recommendation.txt

Modified: trunk/ADC-PRD.txt
===================================================================
--- trunk/ADC-PRD.txt	2013-06-30 13:32:30 UTC (rev 108)
+++ trunk/ADC-PRD.txt	2013-06-30 13:47:09 UTC (rev 109)
@@ -1,5 +1,6 @@
 = ADC - Protocol Release Description
-1.0.0, UNRELEASED
+Fredrik Ullner, <ul...@gm...>
+1.0.0, June 2013
 
 == Abstract
 New versions of ADC are released on a continuous basis. This document intend to provide a resource for those who are active in the ADC developent process and particularly the release process. This document, Protocol Release Description (PRD), describes the necessary changes and updates to the ADC network and associated resources once a new version of ADC is about to be released and subsequently is released.

Modified: trunk/ADC-Recommendation.txt
===================================================================
--- trunk/ADC-Recommendation.txt	2013-06-30 13:32:30 UTC (rev 108)
+++ trunk/ADC-Recommendation.txt	2013-06-30 13:47:09 UTC (rev 109)
@@ -49,4 +49,14 @@
 53 | Similar to error code 11.
 54 | Must be 2 (fatal).
 
+== ZLIB compression
+
+=== Generic
+
+* Try to keep constant and almost constant named parameters together, that way there is a higher likelyhood for a longer parameter match.
+
+* When possible try to keep similar commands no more than a window size (usually 32 bits if highest rate is used) away, that ensures you will benefit from the redundancy provided by these (this may be particularly important when sending large strings like MOTDs or help and configuration values intertwined with other commands).
+
+* Syncing is important to keep the clients updated but when you sync some bytes are sent (the sync ones and the ones for the Huffman tree of the new packet if it is a type 2 packet) as such it may make sense to keep in different queues commands depending on how much latency matters for them, for example you may want to keep low latency for MSG commands and send them frequently but may prefer to send searches or passive results together each half second or so. Also latencies matter depending on the type of network, on a LAN users expect most things to happen almost inmediately (especially things like MSGs) whilst clients connecting over a classic DSL line may not care that much for higher latencies.
+
 // vim: set syntax=asciidoc:

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.