[Dcplusplus-commit] SF.net SVN: dcplusplus: [923] dcplusplus/trunk/ADC.txt

[<arn...@us...>]

Revision: 923
          http://dcplusplus.svn.sourceforge.net/dcplusplus/?rev=923&view=rev
Author:   arnetheduck
Date:     2007-12-01 13:15:53 -0800 (Sat, 01 Dec 2007)

Log Message:
-----------
ADC 1.0

Modified Paths:
--------------
    dcplusplus/trunk/ADC.txt

Modified: dcplusplus/trunk/ADC.txt
===================================================================
--- dcplusplus/trunk/ADC.txt	2007-12-01 14:43:52 UTC (rev 922)
+++ dcplusplus/trunk/ADC.txt	2007-12-01 21:15:53 UTC (rev 923)
@@ -1,4 +1,4 @@
-= ADC Protocol Draft
+= ADC Protocol
 Jacek Sieka <arn...@gm...>
 1.0, December 2007
 
@@ -19,18 +19,23 @@
 Ullner, Fredrik Stenberg and others. Jon Hess contributed the original Direct
 Connect idea through the Neo-Modus Direct Connect client / hub.
 
-The latest draft version of this document can be downloaded from
+== Version history
+The latest draft of the next version of this document as well as intermediate
+and older versions can be downloaded from
 $URL$. 
 This version correspods to $Revision$.
 
+=== Version 1.0, 2007-12-01
+* Initial release
+
 == Line protocol
 === General
 * All messages begin with a four-letter word. The first letter designates how
   the message should be sent and the other three specify what to do.
 * Parameters are separated by space and a newline (codepoint 0x0a) ends each
   message. The string "\s" escapes space, "\n" newline and "\\" backslash.
-  This version of the protocol reserves all other escapes for future use; 
-  any message containing unknown escapes must be discarded.
+  This version of the protocol reserves all other escapes for future use; any
+  message containing unknown escapes must be discarded.
 * All text must be sent as UTF-8 encoded Unicode in normalization form C.
 * Clients must ignore unknown/badly formatted messages. Hubs must ignore
   invalid messages and should dispatch unknown messages according to their
@@ -39,10 +44,10 @@
   IPv4 and RFC 1884 form for IPv6. Hub addresses must be specified in URL
   form, with "adc" as protocol specifier ("adc://server:port/").
 * Numbers are sent as strings in standard floating point notation, using '.'
-  as the decimal separator and without a thousands separator. Integers are numbers
-  with neither a decimal portion nor an exponent. Applications should be
-  prepared to handle at least 64-bit signed integers and 64-bit floating point
-  numbers. A '-' prefix negates.
+  as the decimal separator and without a thousands separator. Integers are
+  numbers with neither a decimal portion nor an exponent. Applications should
+  be prepared to handle at least 64-bit signed integers and 64-bit floating
+  point numbers. A '-' prefix negates.
 * SIDs, PIDs, CIDs, and short binary data are sent as base32-encoded strings.
   Long binary data transfers should use the file transfer mechanism with named
   roots.
@@ -50,10 +55,10 @@
   only include viewable characters that can be encoded by one byte in the
   UTF-8 encoding (Unicode codepoints 33-127). ADC is case-sensitive, requiring
   upper case for command names.
-* Some commands and functionality require the use of a hash function.
-  The hash function is negotiated during session setup and stays the same for
-  the duration of the session.
-  
+* Some commands and functionality require the use of a hash function.  The
+  hash function is negotiated during session setup and stays the same for the
+  duration of the session.
+
 === Message syntax
 ..................
 message               ::= message_body? eol
@@ -486,7 +491,7 @@
 CT   | integer | Client (user) type, 1=bot, 2=registered user, 4=operator, 8=super user, 16=hub owner, 32=hub (used when the hub sends an INF about itself). Multiple types are specified by adding the numbers together.
 AW   | integer | 1=Away, 2=Extended away, not interested in hub chat (hubs may skip sending broadcast type MSG commands to clients with this flag)
 SU   | string  | Comma-separated list of feature FOURCC's. This notifies other clients of extended capabilities of the connecting client.
-RF   | string  | URL of referxrer (hub in case of redirect, web page)
+RF   | string  | URL of referer (hub in case of redirect, web page)
 ___
 
 NOTE: Normally one would only accept an IP (I4 or I6) that is the same as the
@@ -499,8 +504,8 @@
 PD and ID fields, and proceed to the VERIFY state by sending a PAS request or
 NORMAL state by sending its own INF (unless it already did so previously),
 then the INF of all connected clients in NORMAL state, and last the INF of the
-connecting client. When the hub that sends an INF about itself, the NI becomes
-hub name, the VE the hub version, and DE the hub description.
+connecting client. When the hub sends an INF about itself, the NI becomes hub
+name, the VE the hub version, and DE the hub description.
 
 When the server receives this during client-client communication in IDENTIFY
 state, it should verify the ID and TO fields, send an INF about itself and


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