From 2d5ebc971cda46656cb36e9aeca7590fa0a7e393 Mon Sep 17 00:00:00 2001
From: zzz <zzz@mail.i2p>
Date: Sun, 14 Sep 2014 17:56:21 +0000
Subject: [PATCH] SSU data packet ACK bitfield notes Transport notes
---
i2p2www/pages/site/docs/spec/ssu.html | 8 ++++++++
i2p2www/pages/site/docs/transport/index.html | 10 ++++++++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/i2p2www/pages/site/docs/spec/ssu.html b/i2p2www/pages/site/docs/spec/ssu.html
index 3e06f8f3e..54274cf52 100644
--- a/i2p2www/pages/site/docs/spec/ssu.html
+++ b/i2p2www/pages/site/docs/spec/ssu.html
@@ -913,6 +913,14 @@ the message ID must be an actual random number.
Because there are no sequence numbers, there is no way to be sure an ACK was received.
The current implementation routinely sends a large amount of duplicate ACKs.
Duplicate ACKs should not be taken as an indication of congestion.
+</li><li>
+ACK Bitfield notes:
+The receiver of a data packet does not know how many fragments are in the message unless it has
+received the last fragment. Therefore, the number of bitfield bytes sent in response may be less or
+more than the number of fragments divided by 7.
+For example, if the highest fragment the receiver has seen is number 4, only
+one byte is required to be sent, even if there may be 13 fragments total.
+Up to 10 bytes (i.e. (64 / 7) + 1) may be included for each message ID acked.
</li></ul>
diff --git a/i2p2www/pages/site/docs/transport/index.html b/i2p2www/pages/site/docs/transport/index.html
index 2814e1e0e..6f23a61e2 100644
--- a/i2p2www/pages/site/docs/transport/index.html
+++ b/i2p2www/pages/site/docs/transport/index.html
@@ -1,7 +1,7 @@
{% extends "global/layout.html" %}
{% block title %}{% trans %}Transport Overview{% endtrans %}{% endblock %}
-{% block lastupdated %}{% trans %}December 2013{% endtrans %}{% endblock %}
-{% block accuratefor %}0.9.9{% endblock %}
+{% block lastupdated %}{% trans %}September 2014{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9.15{% endblock %}
{% block content %}
<h2>{% trans %}Transports in I2P{% endtrans %}</h2>
@@ -39,6 +39,7 @@ Reliable delivery of <a href="{{ i2np }}">I2NP</a> messages.
Transports support I2NP message delivery ONLY.
They are not general-purpose data pipes.
{%- endtrans %}</li>
+<li>{% trans %}In-order delivery of messages is NOT guaranteed by all transports.{% endtrans %}</li>
<li>{% trans -%}
Maintain a set of router addresses, one or more for each transport,
that the router publishes as its global contact information (the RouterInfo).
@@ -80,6 +81,10 @@ These addresses constitute the advertised contact points, and are published by t
Addresses may also contain an arbitrary set of additional options.
{%- endtrans %}</p>
+<p>{% trans -%}
+Each transport method may publish multiple router addresses.
+{%- endtrans %}</p>
+
<p>{% trans %}Typical scenarios are:{% endtrans %}
<ul>
<li>{% trans %}A router has no published addresses, so it is considered "hidden" and cannot receive incoming connections{% endtrans %}</li>
@@ -145,6 +150,7 @@ Additional transports may be developed, including:
<ul>
<li>{% trans %}A TLS/SSH look-alike transport{% endtrans %}</li>
<li>{% trans %}An "indirect" transport for routers that are not reachable by all other routers (one form of "restricted routes"){% endtrans %}</li>
+<li>{% trans %}Tor-compatible pluggable transports{% endtrans %}</li>
</ul>
<p>{% trans -%}
--
GitLab