diff --git a/i2p2www/pages/site/docs/applications/bittorrent.html b/i2p2www/pages/site/docs/applications/bittorrent.html index cc1cb44d..1f2d4f8e 100644 --- a/i2p2www/pages/site/docs/applications/bittorrent.html +++ b/i2p2www/pages/site/docs/applications/bittorrent.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}Bittorrent over I2P{% endtrans %}{% endblock %} -{% block lastupdated %}{% trans %}January 2017{% endtrans %}{% endblock %} -{% block accuratefor %}0.9.28{% endblock %} +{% block lastupdated %}2022-01{% endblock %} +{% block accuratefor %}0.9.52{% endblock %} {% block content %}
{% trans -%} @@ -71,7 +71,9 @@ There are no known I2P clients or trackers that currently support UDP announce/r
{% trans -%} The non-compact response is just as in standard bittorrent, with an I2P "ip". -{%- endtrans %}
+{%- endtrans %} +This is a long base64-encoded "DNS string", probably with a ".i2p" suffix. +{% trans -%} Trackers generally include a fake port key, or use the port from the announce, for compatibility with older clients. @@ -296,32 +298,8 @@ are described below, and are subject to change. Contact the I2P developers if you wish to develop a client or tracker supporting datagram announces. {%- endtrans %}
-{% trans -%} -A UDP tracker listens on two ports. -The "query port" is the advertised port, and is used to receive repliable (signed) datagrams, for the connect request only. -The "response port" is used to receive unsigned (raw) datagrams, and is the source port for all replies. -The response port is arbitrary. -A client sends and receives on a single port only. -It receives only unsigned (raw) datagrams. -Raw datagrams provides increased efficiency for replies since they contain tokens sent in the query, and need not be signed. -{%- endtrans %}
- -{% trans -%} -In the announce request, the 4-byte IP is replaced by a 32-byte hash, and the port is still present, -although it may be ignored by the tracker. -In the announce response, each 4-byte IP and 2-byte port is replaced by a 32-byte hash (compact peer info), and no port is present. -The client sends the announce request and scrape request to the source port in the announce response packet. -The connect request, connect response, scrape request, scrape response, and error response are the same as in BEP 15. -{%- endtrans %}
- -{% trans -%} -Source addresses in I2P cannot be spoofed, so it is possible to use a simplified protocol -with 2 packets instead of 4, omitting the connect request and response. -In this case, the announce request would be a repliable datagram sent to the tracker's query port, -and the tracker would not require a response port. -While this is more efficient, it would be more difficult to modify an existing tracker to support this mode. -The URL for the 4-packet-mode tracker would use standard "udp://" prefix. -The URL for a modified 2-packet-mode tracker would require a different prefix if both modes are supported in I2P. +
{% trans prop160=site_url('docs/spec/proposals/160) -%} +See Proposal 160. {%- endtrans %}
diff --git a/i2p2www/spec/proposals/160-udp-trackers.rst b/i2p2www/spec/proposals/160-udp-trackers.rst new file mode 100644 index 00000000..6404eff9 --- /dev/null +++ b/i2p2www/spec/proposals/160-udp-trackers.rst @@ -0,0 +1,378 @@ +================================ +UDP Trackers +================================ +.. meta:: + :author: zzz + :created: 2022-01-03 + :thread: http://zzz.i2p/topHTTP/1.1 200 OK Cache-Control: max-age=0, private, must-revalidate, no-transform Set-Cookie: i_like_gitea=8f9e1c17570092a3; Path=/; HttpOnly; Secure; SameSite=Lax Set-Cookie: _csrf=pwZQ5UxmDYHuYs-Vbl7BhR_gjnY6MTc1MzI5ODA4ODU3MjU4OTk3NA; Path=/; Max-Age=86400; HttpOnly; Secure; SameSite=Lax X-Frame-Options: SAMEORIGIN Date: Wed, 23 Jul 2025 19:14:48 GMT Content-Type: text/plain; charset=utf-8 Connection: close Transfer-Encoding: chunked X-Cache-Status: HIT X-Cache-Age: 0 3a3a diff --git a/i2p2www/pages/site/docs/applications/bittorrent.html b/i2p2www/pages/site/docs/applications/bittorrent.html index cc1cb44d..1f2d4f8e 100644 --- a/i2p2www/pages/site/docs/applications/bittorrent.html +++ b/i2p2www/pages/site/docs/applications/bittorrent.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}{% trans %}Bittorrent over I2P{% endtrans %}{% endblock %} -{% block lastupdated %}{% trans %}January 2017{% endtrans %}{% endblock %} -{% block accuratefor %}0.9.28{% endblock %} +{% block lastupdated %}2022-01{% endblock %} +{% block accuratefor %}0.9.52{% endblock %} {% block content %}{% trans -%} @@ -71,7 +71,9 @@ There are no known I2P clients or trackers that currently support UDP announce/r
{% trans -%} The non-compact response is just as in standard bittorrent, with an I2P "ip". -{%- endtrans %}
+{%- endtrans %} +This is a long base64-encoded "DNS string", probably with a ".i2p" suffix. +{% trans -%} Trackers generally include a fake port key, or use the port from the announce, for compatibility with older clients. @@ -296,32 +298,8 @@ are described below, and are subject to change. Contact the I2P developers if you wish to develop a client or tracker supporting datagram announces. {%- endtrans %}
-{% trans -%} -A UDP tracker listens on two ports. -The "query port" is the advertised port, and is used to receive repliable (signed) datagrams, for the connect request only. -The "response port" is used to receive unsigned (raw) datagrams, and is the source port for all replies. -The response port is arbitrary. -A client sends and receives on a single port only. -It receives only unsigned (raw) datagrams. -Raw datagrams provides increased efficiency for replies since they contain tokens sent in the query, and need not be signed. -{%- endtrans %}
- -{% trans -%} -In the announce request, the 4-byte IP is replaced by a 32-byte hash, and the port is still present, -although it may be ignored by the tracker. -In the announce response, each 4-byte IP and 2-byte port is replaced by a 32-byte hash (compact peer info), and no port is present. -The client sends the announce request and scrape request to the source port in the announce response packet. -The connect request, connect response, scrape request, scrape response, and error response are the same as in BEP 15. -{%- endtrans %}
- -{% trans -%} -Source addresses in I2P cannot be spoofed, so it is possible to use a simplified protocol -with 2 packets instead of 4, omitting the connect request and response. -In this case, the announce request would be a repliable datagram sent to the tracker's query port, -and the tracker would not require a response port. -While this is more efficient, it would be more difficult to modify an existing tracker to support this mode. -The URL for the 4-packet-mode tracker would use standard "udp://" prefix. -The URL for a modified 2-packet-mode tracker would require a different prefix if both modes are supported in I2P. +
{% trans prop160=site_url('docs/spec/proposals/160) -%} +See Proposal 160. {%- endtrans %}
diff --git a/i2p2www/spec/proposals/160-udp-trackers.rst b/i2p2www/spec/proposals/160-udp-trackers.rst new file mode 100644 index 00000000..6404eff9 --- /dev/null +++ b/i2p2www/spec/proposals/160-udp-trackers.rst @@ -0,0 +1,378 @@ +================================ +UDP Trackers +================================ +.. meta:: + :author: zzz + :created: 2022-01-03 + :thread: http://zzz.i2p/top 0