Menu
▾
▴
[Dcplusplus-commit] SF.net SVN: adc:[94] trunk/ADC.txt
|
From: <ul...@us...> - 2013-01-31 18:45:38
|
Revision: 94
http://adc.svn.sourceforge.net/adc/?rev=94&view=rev
Author: ullner
Date: 2013-01-31 18:45:29 +0000 (Thu, 31 Jan 2013)
Log Message:
-----------
ADC is now at 1.0.3.
Modified Paths:
--------------
trunk/ADC.txt
Modified: trunk/ADC.txt
===================================================================
--- trunk/ADC.txt 2013-01-14 19:00:40 UTC (rev 93)
+++ trunk/ADC.txt 2013-01-31 18:45:29 UTC (rev 94)
@@ -1,6 +1,6 @@
= ADC Protocol
Fredrik Ullner <ul...@gm...>
-1.0.2, November 2012
+1.0.2, January 2013
== Abstract
ADC is a text protocol for a client-server network similar to Neo-Modus'
@@ -14,9 +14,9 @@
this structure. ADC stands for anything you would like it to stand for;
Advanced Direct Connect is the first neutral thing that springs to mind =).
-Many ideas for the protocol come from Jan Vidar Krey's DCTNG draft. Major
-contributors include Dustin Brody, Walter Doekes, Timmo Stange, Fredrik
-Ullner, Fredrik Stenberg and others. Jon Hess contributed the original Direct
+Many ideas for the protocol come from Jan Vidar Krey's DCTNG draft. Major
+contributors include Dustin Brody, Walter Doekes, Timmo Stange, Fredrik
+Ullner, Fredrik Stenberg and others. Jon Hess contributed the original Direct
Connect idea through the Neo-Modus Direct Connect client / hub.
== Version history
@@ -25,7 +25,7 @@
$URL$.
This version corresponds to $Revision$.
-=== Version 1.0.2, UNRELEASED
+=== Version 1.0.3, 2013-01-31
Fredrik Ullner <ul...@gm...>
* Editorial updates
@@ -114,7 +114,7 @@
message type only to aid in parsing the message and otherwise ignore it. The
following message types are defined:
-[options="autowidth"]
+[options="autowidth"]
|=====
|B |Broadcast |Hub must send message to all connected clients, including the sender of the message.
|C |Client message |Clients must use this message type when communicating directly over TCP.
@@ -328,7 +328,7 @@
clients may support using the message in additional contexts as well. The
context codes are as follows:
-[options="autowidth"]
+[options="autowidth"]
|=====
|F |From hub (hub-client TCP)
|T |To hub (hub-client TCP)
@@ -342,73 +342,73 @@
In the descriptions of the commands, the message header and trailing named
parameters have been omitted.
-=== State management
-
-ADC defines a state machine to control flow and processing of messages. The receiving end must ensure, according to the state machine, that it does not parse or drop messages while it is in the process of another state where the message might be invalid.
-
-[options="autowidth, header"]
-|=====
-|State |Description
-|PROTOCOL |Feature support recovery
-|IDENTIFY |User identification and static checks
-|VERIFY |Password check (does not exist in C-C communication unless announced by an extension)
-|NORMAL |Normal operation (end state)
-|DATA |Binary transfers. The state changes back to NORMAL once the transfer is complete.
-|=====
-
-The states presented are the login order, from top to bottom.
-
-==== States
-===== PROTOCOL
-When the hub receives a SUP, it should reply with its own SUP followed by SID assignment. The hub transitions the state then to IDENTIFY.
-
-When the server party receives a SUP in the client-client connection, it should reply with its own SUP. The server transitions the state then to IDENTIFY.
-
-===== IDENTIFY
-The hub may initiate this state by sending its own INF in this state but is not required. The client should send its INF whereupon the hub shall verify the PD and ID fields and other required fields. The hub transitions the state then to VERIFY if the user is registered or NORMAL if not.
-
-The client party in the client-client connection shall send its INF whereupon the server party shall send its INF. The server transitions the state then to NORMAL (or VERIFY if an extension implements this).
-
-===== VERIFY
-The hub shall send a GPA whereupon the client will respond with a PAS. The server transitions the state then to NORMAL.
-
-Client-client support for VERIFY must be signaled as an extension.
-
-===== NORMAL
-The hub should send its INF if not done already. The server shall send the INF of all connected clients whereupon the connecting client's INF shall be last. Normal operation may then commence with chatting and file sharing.
-
-Normal operation may commence immediately in a client-client connection. Typically, the downloading party sends a GET whereupon the other party sends a SND followed by a transition to the DATA state.
-
-===== DATA
-The DATA state is an actual binary transfer state, it does not have any commands or other content beyond streaming data.
-
-The DATA state exist only in the client-client communication, an extension can be used to add binary transfers between a client and a hub. The DATA state commence after a SND command.
-
-The state transitions back to NORMAL once the correct amount of bytes are transferred (specified by a previous command).
-
-==== Notes
-State always transitions from PROTOCOL to IDENTIFY and never from IDENTIFY to PROTOCOL. Likewise apply between IDENTIFY, VERIFY and NORMAL. This does not apply between NORMAL and DATA.
-
-Successful commands sent after a state transition indicate that the next state has been reached. For example, PROTOCOL begins a connection and state changes to IDENTIFY once the hub sends the SID.
-
-The state is shared between the client and the server while the server (implicitly) controls state transitions.
-
-The connecting party is known as the client and the other is known as the server (or hub). The client initiates the connection and state machine by sending its own SUP.
-
-A STA is valid in all states (except DATA) and may require that messages are resent (i.e. that the state transition does not occur).
-
-It is always the client party in a client-client connection that sent the connection request (CTM/RCM) command that is given control of the connection once the NORMAL state has been reached.
-
-Any party may disconnect the connection if they receive invalid data or insufficient data. All implementations must therefore be prepared for a potential disconnection following each command, meaning that the following state is not achieved. A disconnection should be preceded by a STA or a QUI to indicate what was wrong.
-
-The hub's INF is optionally sent in IDENTIFY or in NORMAL.
-
-[options="autowidth, header"]
-|=====
-|State |Commands
-|PROTOCOL |STA, SUP, SID
-|IDENTIFY |STA, INF, QUI
-|VERIFY |STA, GPA, PAS, QUI
+=== State management
+
+ADC defines a state machine to control flow and processing of messages. The receiving end must ensure, according to the state machine, that it does not parse or drop messages while it is in the process of another state where the message might be invalid.
+
+[options="autowidth, header"]
+|=====
+|State |Description
+|PROTOCOL |Feature support recovery
+|IDENTIFY |User identification and static checks
+|VERIFY |Password check (does not exist in C-C communication unless announced by an extension)
+|NORMAL |Normal operation (end state)
+|DATA |Binary transfers. The state changes back to NORMAL once the transfer is complete.
+|=====
+
+The states presented are the login order, from top to bottom.
+
+==== States
+===== PROTOCOL
+When the hub receives a SUP, it should reply with its own SUP followed by SID assignment. The hub transitions the state then to IDENTIFY.
+
+When the server party receives a SUP in the client-client connection, it should reply with its own SUP. The server transitions the state then to IDENTIFY.
+
+===== IDENTIFY
+The hub may initiate this state by sending its own INF in this state but is not required. The client should send its INF whereupon the hub shall verify the PD and ID fields and other required fields. The hub transitions the state then to VERIFY if the user is registered or NORMAL if not.
+
+The client party in the client-client connection shall send its INF whereupon the server party shall send its INF. The server transitions the state then to NORMAL (or VERIFY if an extension implements this).
+
+===== VERIFY
+The hub shall send a GPA whereupon the client will respond with a PAS. The server transitions the state then to NORMAL.
+
+Client-client support for VERIFY must be signaled as an extension.
+
+===== NORMAL
+The hub should send its INF if not done already. The server shall send the INF of all connected clients whereupon the connecting client's INF shall be last. Normal operation may then commence with chatting and file sharing.
+
+Normal operation may commence immediately in a client-client connection. Typically, the downloading party sends a GET whereupon the other party sends a SND followed by a transition to the DATA state.
+
+===== DATA
+The DATA state is an actual binary transfer state, it does not have any commands or other content beyond streaming data.
+
+The DATA state exist only in the client-client communication, an extension can be used to add binary transfers between a client and a hub. The DATA state commence after a SND command.
+
+The state transitions back to NORMAL once the correct amount of bytes are transferred (specified by a previous command).
+
+==== Notes
+State always transitions from PROTOCOL to IDENTIFY and never from IDENTIFY to PROTOCOL. Likewise apply between IDENTIFY, VERIFY and NORMAL. This does not apply between NORMAL and DATA.
+
+Successful commands sent after a state transition indicate that the next state has been reached. For example, PROTOCOL begins a connection and state changes to IDENTIFY once the hub sends the SID.
+
+The state is shared between the client and the server while the server (implicitly) controls state transitions.
+
+The connecting party is known as the client and the other is known as the server (or hub). The client initiates the connection and state machine by sending its own SUP.
+
+A STA is valid in all states (except DATA) and may require that messages are resent (i.e. that the state transition does not occur).
+
+It is always the client party in a client-client connection that sent the connection request (CTM/RCM) command that is given control of the connection once the NORMAL state has been reached.
+
+Any party may disconnect the connection if they receive invalid data or insufficient data. All implementations must therefore be prepared for a potential disconnection following each command, meaning that the following state is not achieved. A disconnection should be preceded by a STA or a QUI to indicate what was wrong.
+
+The hub's INF is optionally sent in IDENTIFY or in NORMAL.
+
+[options="autowidth, header"]
+|=====
+|State |Commands
+|PROTOCOL |STA, SUP, SID
+|IDENTIFY |STA, INF, QUI
+|VERIFY |STA, GPA, PAS, QUI
|NORMAL |STA, SUP, INF, MSG, SCH, RES, CTM, RCM, QUI, GET, GFI, SND
|=====
@@ -426,7 +426,7 @@
Severity values:
-[options="autowidth"]
+[options="autowidth"]
|=====
|0 |Success (used for confirming commands), error code must be "00", and an additional flag "FC" contains the FOURCC of the command being confirmed if applicable.
|1 |Recoverable (error but no disconnect)
@@ -435,7 +435,7 @@
Error codes:
-[options="autowidth"]
+[options="autowidth"]
|=====
|00 |Generic, show description
|x0 |Same as 00, but categorized according to the rough structure set below
@@ -528,7 +528,7 @@
Fields:
-[options="autowidth,header"]
+[options="autowidth,header"]
|=====
|Code |Type |Description
|ID |base32 |The CID of the client. Mandatory for C-C connections.
@@ -579,7 +579,7 @@
Flags:
-[options="autowidth"]
+[options="autowidth"]
|=====
|PM<group-SID> |Private message, <group-SID> is the SID clients must send responses to. This field must contain the originating SID if this is a normal private conversation.
|ME |Speak in third person, 1 = message should be displayed as /me in IRC ("*nick text")
@@ -598,7 +598,7 @@
unless no known fields are present in which case the client must ignore the
search.
-[options="autowidth"]
+[options="autowidth"]
|=====
|AN, NO, EX |String search term, where AN is include (and), NO is exclude (and not), and EX is extension. Each filename (including the path to it) should be matched using case insensitive substring search as follows: match all AN, remove those that match any NO, and make sure the extension matches at least one of the EX (if it is present). Extensions must be sent without the leading period (\'.').
|LE |Smaller (less) than or equal size in bytes
@@ -624,7 +624,7 @@
encouraged to supply additional fields if available. Passive results should be
limited to 5 and active to 10.
-[options="autowidth"]
+[options="autowidth"]
|=====
|FN |Full filename including path in share
|SI |Size, in bytes
@@ -693,7 +693,7 @@
The following flags may be present:
-[options="autowidth"]
+[options="autowidth"]
|=====
|ID |SID of the initiator of the disconnect (for example the one that issued a kick).
|TL |Time Left until reconnect is allowed, in seconds. -1 = forever.
@@ -761,7 +761,7 @@
== Examples
=== Client – Hub connection
-[options="autowidth,header"]
+[options="autowidth,header"]
|=====
|Client |Hub
|HSUP ADBASE ADTIGR ...|
@@ -778,7 +778,7 @@
=== Client – Client connection
-[options="autowidth,header"]
+[options="autowidth,header"]
|=====
|Client |Server
|CSUP ADBASE ADTIGR ... |
@@ -795,9 +795,9 @@
[options="autowidth,header"]
|=====
|Term |Description
-|FOURCC |Four character code. This may be the message type followed by the command, e.g. "ISTA", "BMSG" etc. This may also be the name of a feature (BASE, TIGR etc). Any four character identification.
-|Server |The hub is the 'server' in a client - hub context. The client receiving the incoming connection is the 'server' in a client - client context.
-|Base32 |An encoding used by the protocol, see RFC 4648 for more information about Base32. Note that the Base32 implementation in ADC is never padded.
+|FOURCC |Four character code. This may be the message type followed by the command, e.g. "ISTA", "BMSG" etc. This may also be the name of a feature (BASE, TIGR etc). Any four character identification.
+|Server |The hub is the 'server' in a client - hub context. The client receiving the incoming connection is the 'server' in a client - client context.
+|Base32 |An encoding used by the protocol, see RFC 4648 for more information about Base32. Note that the Base32 implementation in ADC is never padded.
|Context |When a command states a context, e.g. "T" (To hub), it defines an expectance on the flow of traffic. A context may refer to one or multiple message types. For example, for the context 'T', the message types "B", "C", "D", "E", "F" and "H" are valid. Note that the context is not a restriction in any way, implementations may further extend a command's expected contexts.
|=====
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
