Menu
▾
▴
[Dcplusplus-commit] SF.net SVN: adc:[124] trunk
|
From: <ul...@us...> - 2014-08-05 12:42:47
|
Revision: 124
http://sourceforge.net/p/adc/code/124
Author: ullner
Date: 2014-08-05 12:42:42 +0000 (Tue, 05 Aug 2014)
Log Message:
-----------
Updated recommendations to include a partial client/hub implementation
Modified Paths:
--------------
trunk/ADC-Recommendation.html
trunk/ADC-Recommendation.txt
Modified: trunk/ADC-Recommendation.html
===================================================================
--- trunk/ADC-Recommendation.html 2014-07-03 19:29:18 UTC (rev 123)
+++ trunk/ADC-Recommendation.html 2014-08-05 12:42:42 UTC (rev 124)
@@ -734,10 +734,7 @@
<body class="article">
<div id="header">
<h1>ADC Recommendations</h1>
-<span id="author">Fredrik Ullner</span><br />
-<span id="email"><code><<a href="mailto:ul...@gm...">ul...@gm...</a>></code></span><br />
-<span id="revnumber">version 1.1.0,</span>
-<span id="revdate">December 2013</span>
+<span id="author">version 1.2.0, UNRELEASED</span><br />
<div id="toc">
<div id="toctitle">Table of Contents</div>
<noscript><p><b>JavaScript must be enabled in your browser to display the table of contents.</b></p></noscript>
@@ -758,7 +755,17 @@
$URL: <a href="https://svn.code.sf.net/p/adc/code/trunk/ADC-Recommendation.txt">https://svn.code.sf.net/p/adc/code/trunk/ADC-Recommendation.txt</a> $.</p></div>
<div class="paragraph"><p>This version corresponds to $Revision: 1 $.</p></div>
<div class="sect2">
-<h3 id="_version_1_1_0_2013_12_21">2.1. Version 1.1.0, 2013-12-21</h3>
+<h3 id="_version_1_2_0_unreleased">2.1. Version 1.2.0, UNRELEASED</h3>
+<div class="ulist"><ul>
+<li>
+<p>
+Added client and hub implementation outlines
+</p>
+</li>
+</ul></div>
+</div>
+<div class="sect2">
+<h3 id="_version_1_1_0_2013_12_21">2.2. Version 1.1.0, 2013-12-21</h3>
<div class="paragraph"><p>Fredrik Ullner, <<a href="mailto:ul...@gm...">ul...@gm...</a>></p></div>
<div class="ulist"><ul>
<li>
@@ -774,7 +781,7 @@
</ul></div>
</div>
<div class="sect2">
-<h3 id="_version_1_0_0_2010_07_01">2.2. Version 1.0.0, 2010-07-01</h3>
+<h3 id="_version_1_0_0_2010_07_01">2.3. Version 1.0.0, 2010-07-01</h3>
<div class="paragraph"><p>Fredrik Ullner, <<a href="mailto:ul...@gm...">ul...@gm...</a>></p></div>
<div class="ulist"><ul>
<li>
@@ -1169,12 +1176,213 @@
</div>
</div>
</div>
+<div class="sect1">
+<h2 id="_client_implementation">7. Client implementation</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>A client can be implemented by following this rough outline. The outline may not specify everything to full detail and will not cover the actual application that shall employ the mechanisms.</p></div>
+<div class="paragraph"><p>There are six sections that need to be implemented to support the major parts of the protocol. They are, in order: connectivity, chatting, downloading, sharing/uploading, search/response. The left out section ("other") is strict protocol compatibility, for additional items that are not necessary to support at first: these things should be implemented alongside basic support for each section.</p></div>
+<div class="paragraph"><p>This outline assumes that there is a hub available and (for the relevant sections) that another client is present.</p></div>
+<div class="paragraph"><p>No part of this outline requires a particular programming language.</p></div>
+<div class="paragraph"><p>Note that all messages end with a newline, which are excluded from this description.</p></div>
+<div class="sect2">
+<h3 id="_connectivity">7.1. Connectivity</h3>
+<div class="paragraph"><p>This section describes the necessary parts to implement basic connectivity to a hub. The client will, after this stage, be able to continue on with chatting or file sharing. Without basic connectivity, obviously nothing can done in the client.</p></div>
+<div class="sect3">
+<h4 id="_steps">7.1.1. Steps</h4>
+<div class="olist arabic"><ol class="arabic">
+<li>
+<p>
+Create a network connection to a hub on the appropriate port.
+</p>
+</li>
+<li>
+<p>
+The client shall send the following message:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+HSUP ADBASE ADTIGR
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+This indicates that the client is notifying the hub about supporting the base protocol (BASE) and the extension hash method Tiger (TIGR). If the protocol base version is changed, send that instead of BASE. Similarly, if another hash method is preferred, send that instead.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+The hub will send:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+ISUP ADBASE ADTIGR
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+The hub may include other things it "AD"s, but none of these are interesting.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+The hub will send:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+ISID ABCD
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+ABCD is the SID that shall be used in any further communication from the client (where applicable). Store this value.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+Optionally, a hub may send the following but is not required:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+IINF CT32 NIhub_name
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+None of these parameters are needed for continuing the connectivity, although may come in handy in the future. The value in the NI parameter can be used for e.g. the application or tab name.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+The client shall send the following message
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+BINF ABCD ID<CID> PD<PID> NImy_name
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+ABCD here is the SID as previously mentioned. The CID and PID are complementary information and are specified in the "Client identification section". The client should generate an internal CID (and associated PID). The CID and PID that the client sends to the hub have been run through a Base32 conversion.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+If the hub did not send its "IINF" before, it may do so now. Again, the information shouldn’t be deemed as required.
+</p>
+</li>
+<li>
+<p>
+The hub may send a password request, see section "Other".
+</p>
+</li>
+<li>
+<p>
+The hub will send all other users that are logged in:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+BINF sid ID<CID> NI<nick>
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+Where SID and CID is the client information. The SID is used to create a mapping between client → user. Note that the PID is never broadcast.
+</p>
+</li>
+</ul></div>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+The last BINF to arrive will be the information you connected with:
+</p>
+<div class="ulist"><ul>
+<li>
+<p>
+BINF ABCD ID<your-CID> NImy_name
+</p>
+</li>
+</ul></div>
+</li>
+<li>
+<p>
+The client will now be fully logged in.
+</p>
+</li>
+</ol></div>
</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_hub_implementation">8. Hub implementation</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>1) Hub accepts network connection.
+- [client state = new]</p></div>
+<div class="paragraph"><p>2) Hub waits for handshake from client.
+Client: HSUP ADBASE …</p></div>
+<div class="paragraph"><p>3) Hub checks support line responds
+Server: ISUP ADBASE …</p></div>
+<div class="paragraph"><p>4) Hub allocates a SID, and sends it to the client.
+Server: ISID …</p></div>
+<div class="paragraph"><p>5) Hub sends the hub information to the client.
+Server: IINF …</p></div>
+<div class="paragraph"><p>6) Hub waits for client to send info:
+- [client state = identify]
+Client: BINF …</p></div>
+<div class="paragraph"><p>7) Hub validates info from client
+ If password verification is needed, then go to 7.1, otherwise 8.</p></div>
+<div class="paragraph"><p>7.1) If user needs to log in, request password
+- [client state = verify]
+Server: IGPA …</p></div>
+<div class="paragraph"><p>7.2) Wait for and verify password from
+Client: HPAS …</p></div>
+<div class="paragraph"><p>8) Hub transmits the userlist of all existing users to the client.
+Server: BINF …
+Server: BINF …
+…
+Server: BINF …</p></div>
+<div class="paragraph"><p>9) Hub broadcasts the client’s info (BINF) to all users, including the client.
+- [client state = NORMAL]
+Server: BINF …</p></div>
+<div class="paragraph"><p>10) At this point the client is considered logged in, and will receive all
+broadcast messages and all direct messages from other clients.
+It will also forward messages originating from this client to others, if the
+messages are correct (syntax, formatting, source SID, etc).</p></div>
+</div>
+</div>
+</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Version 1.1.0<br />
-Last updated 2014-01-19 17:26:27 W. Europe Standard Time
+Last updated 2014-08-05 14:38:44 W. Europe Daylight Time
</div>
</div>
</body>
Modified: trunk/ADC-Recommendation.txt
===================================================================
--- trunk/ADC-Recommendation.txt 2014-07-03 19:29:18 UTC (rev 123)
+++ trunk/ADC-Recommendation.txt 2014-08-05 12:42:42 UTC (rev 124)
@@ -1,6 +1,5 @@
= ADC Recommendations
-Fredrik Ullner <ul...@gm...>
-1.1.0, December 2013
+version 1.2.0, UNRELEASED
== Abstract
These are the official recommendations to ADC. This document is based on the information contained in the ADC documents, ADC wiki and ADC blog. Information is this document should be taken as guide lines to implementations.
@@ -12,6 +11,10 @@
This version corresponds to $Revision: 1 $.
+=== Version 1.2.0, UNRELEASED
+
+* Added client and hub implementation outlines
+
=== Version 1.1.0, 2013-12-21
Fredrik Ullner, <ul...@gm...>
@@ -160,4 +163,92 @@
* Information leak: you can find out the max user peak of the hub in a session.
* The SID array grows when more clients logout then login; in worst case, the hub is empty and the array contains all created SIDs of the session.
+== Client implementation
+A client can be implemented by following this rough outline. The outline may not specify everything to full detail and will not cover the actual application that shall employ the mechanisms.
+
+There are six sections that need to be implemented to support the major parts of the protocol. They are, in order: connectivity, chatting, downloading, sharing/uploading, search/response. The left out section ("other") is strict protocol compatibility, for additional items that are not necessary to support at first: these things should be implemented alongside basic support for each section.
+
+This outline assumes that there is a hub available and (for the relevant sections) that another client is present.
+
+No part of this outline requires a particular programming language.
+
+Note that all messages end with a newline, which are excluded from this description.
+
+=== Connectivity
+This section describes the necessary parts to implement basic connectivity to a hub. The client will, after this stage, be able to continue on with chatting or file sharing. Without basic connectivity, obviously nothing can done in the client.
+
+==== Steps
+1. Create a network connection to a hub on the appropriate port.
+2. The client shall send the following message:
+* HSUP ADBASE ADTIGR
+** This indicates that the client is notifying the hub about supporting the base protocol (BASE) and the extension hash method Tiger (TIGR). If the protocol base version is changed, send that instead of BASE. Similarly, if another hash method is preferred, send that instead.
+3. The hub will send:
+* ISUP ADBASE ADTIGR
+** The hub may include other things it "AD"s, but none of these are interesting.
+4. The hub will send:
+* ISID ABCD
+** ABCD is the SID that shall be used in any further communication from the client (where applicable). Store this value.
+5. Optionally, a hub may send the following but is not required:
+* IINF CT32 NIhub_name
+** None of these parameters are needed for continuing the connectivity, although may come in handy in the future. The value in the NI parameter can be used for e.g. the application or tab name.
+6. The client shall send the following message
+* BINF ABCD ID<CID> PD<PID> NImy_name
+** ABCD here is the SID as previously mentioned. The CID and PID are complementary information and are specified in the "Client identification section". The client should generate an internal CID (and associated PID). The CID and PID that the client sends to the hub have been run through a Base32 conversion.
+7. If the hub did not send its "IINF" before, it may do so now. Again, the information shouldn't be deemed as required.
+8. The hub may send a password request, see section "Other".
+9. The hub will send all other users that are logged in:
+* BINF sid ID<CID> NI<nick>
+** Where SID and CID is the client information. The SID is used to create a mapping between client -> user. Note that the PID is never broadcast.
+10. The last BINF to arrive will be the information you connected with:
+* BINF ABCD ID<your-CID> NImy_name
+11. The client will now be fully logged in.
+
+== Hub implementation
+
+1) Hub accepts network connection.
+- [client state = new]
+
+2) Hub waits for handshake from client.
+Client: HSUP ADBASE ...
+
+3) Hub checks support line responds
+Server: ISUP ADBASE ...
+
+4) Hub allocates a SID, and sends it to the client.
+Server: ISID ...
+
+5) Hub sends the hub information to the client.
+Server: IINF ...
+
+6) Hub waits for client to send info:
+- [client state = identify]
+Client: BINF ...
+
+7) Hub validates info from client
+ If password verification is needed, then go to 7.1, otherwise 8.
+
+7.1) If user needs to log in, request password
+- [client state = verify]
+Server: IGPA ...
+
+7.2) Wait for and verify password from
+Client: HPAS ...
+
+8) Hub transmits the userlist of all existing users to the client.
+Server: BINF ...
+Server: BINF ...
+...
+Server: BINF ...
+
+
+9) Hub broadcasts the client's info (BINF) to all users, including the client.
+- [client state = NORMAL]
+Server: BINF ...
+
+10) At this point the client is considered logged in, and will receive all
+broadcast messages and all direct messages from other clients.
+It will also forward messages originating from this client to others, if the
+messages are correct (syntax, formatting, source SID, etc).
+
+
// vim: set syntax=asciidoc:
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
|
