UDP tracker proposal
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}{% trans %}Bittorrent over I2P{% endtrans %}{% endblock %}
|
||||
{% block lastupdated %}{% trans %}September 2012{% endtrans %}{% endblock %}
|
||||
{% block accuratefor %}0.9.2{% endblock %}
|
||||
{% block lastupdated %}{% trans %}May 2014{% endtrans %}{% endblock %}
|
||||
{% block accuratefor %}0.9.13{% endblock %}
|
||||
{% block content %}
|
||||
|
||||
<p>{% trans -%}
|
||||
@@ -282,6 +282,47 @@ or a list of strings alone.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
|
||||
|
||||
<h2>{% trans %}Datagram (UDP) Trackers{% endtrans %}</h2>
|
||||
<p>{% trans -%}
|
||||
UDP tracker support in clients and trackers is not yet available.
|
||||
Preliminary differences from
|
||||
<a href="http://www.bittorrent.org/beps/bep_0015.html">BEP 15</a>
|
||||
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 %}</p>
|
||||
|
||||
<p>{% 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 %}</p>
|
||||
|
||||
<p>{% 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 %}</p>
|
||||
|
||||
<p>{% 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.
|
||||
{%- endtrans %}</p>
|
||||
|
||||
|
||||
|
||||
|
||||
<h2>{% trans %}Additional Information{% endtrans %}</h2>
|
||||
<ul>
|
||||
<li>{% trans zzz=i2pconv('zzz.i2p') -%}
|
||||
|
Reference in New Issue
Block a user