| 16 | | `Zeroconf`_ is a collection of protocols including ipv4 link local networking, `mDNS`_, and `DNS service-discovery`_. This document aims to outline an extension for BitTorrent clients to allow them to find peers on a local-link network using the zeroconf `DNS service-discovery`_ system. It was written in the hope that clients could standardise the way in which they found peers on the local-link in order to maximize the functionality of the BitTorrent protocol. |
| | 16 | `Zeroconf`_ is a collection of protocols including ipv4 link local |
| | 17 | networking, `mDNS`_, and `DNS service-discovery`_. This document aims |
| | 18 | to outline an extension for BitTorrent clients to allow them to find |
| | 19 | peers on a local-link network using the zeroconf `DNS |
| | 20 | service-discovery`_ system. It was written in the hope that clients |
| | 21 | could standardise the way in which they found peers on the local-link |
| | 22 | in order to maximize the functionality of the BitTorrent protocol. |
| 22 | | Many networks today consist of computers that have a fast network connection (tens or hundreds of megabits/s) to a local area network, in addition to a relatively slower (hundreds of kilobits/s or a few megabits/s) connection to the wider internet. Such networks exist in places such as university colleges, defence barracks and community wifi networks. If two hosts on the same (fast) local-link network wish to download the same torrent at the moment they only share packets across their slow internet connection. The BitTorrent Zeroconf Peer Advertising and Discovery Extension will allow automatic discovery of these peers to each other so that packets can be quickly transfered across the fast local network as opposed to across their slow internet connections. Effectively the effort of downloading the torrent can now be distributed between the hosts on a local-link network. |
| | 28 | Many networks today consist of computers that have a fast network |
| | 29 | connection (tens or hundreds of megabits/s) to a local area network, |
| | 30 | in addition to a relatively slower (hundreds of kilobits/s or a few |
| | 31 | megabits/s) connection to the wider internet. Such networks exist in |
| | 32 | places such as university colleges, defence barracks and community |
| | 33 | wifi networks. If two hosts on the same (fast) local-link network |
| | 34 | wish to download the same torrent at the moment they only share |
| | 35 | packets across their slow internet connection. The BitTorrent Zeroconf |
| | 36 | Peer Advertising and Discovery Extension will allow automatic |
| | 37 | discovery of these peers to each other so that packets can be quickly |
| | 38 | transfered across the fast local network as opposed to across their |
| | 39 | slow internet connections. Effectively the effort of downloading the |
| | 40 | torrent can now be distributed between the hosts on a local-link |
| | 41 | network. |
| 34 | | Note that you can only run one zeroconf instance per host due to it binding to specific ports on your network interfaces, so it is **not** recommended to build the whole zeroconf daemon/server into your client. It is much better plug into a system wide service using the API's: it cuts down your code and allows other services e.g. http, ftp to advertise themselves using the same daemon. |
| | 57 | Note that you can only run one zeroconf instance per host due to it |
| | 58 | binding to specific ports on your network interfaces, so it is **not** |
| | 59 | recommended to build the whole zeroconf daemon/server into your |
| | 60 | client. It is much better plug into a system wide service using the |
| | 61 | API's: it cuts down your code and allows other services e.g. http, ftp |
| | 62 | to advertise themselves using the same daemon. |
| 49 | | The above-mentioned zeroconf implementations provide good documentation for developers on how to do this. If the client uses the same peer-id for all torrents it has loaded, then for each additional torrent file, only the subservice needs to be added. If the client uses a different peer-id for each torrent then a _bittorrent._tcp. service will have to be added for each torrent file with the respective subservice. This is also true if each torrent uses a different port. |
| | 79 | The above-mentioned zeroconf implementations provide good |
| | 80 | documentation for developers on how to do this. If the client uses the |
| | 81 | same peer-id for all torrents it has loaded, then for each additional |
| | 82 | torrent file, only the subservice needs to be added. If the client |
| | 83 | uses a different peer-id for each torrent then a |
| | 84 | _bittorrent._tcp. service will have to be added for each torrent file |
| | 85 | with the respective subservice. This is also true if each torrent uses |
| | 86 | a different port. |
| 55 | | For the Avahi C API use the function ``avahi_entry_group_add_service()`` to establish the parent _bittorrent._tcp service and ``avahi_entry_group_add_service_subtype()`` with ``_<info-hash>._sub._bittorrent._tcp.`` as the 'type' parameter to establish the subservices. For both functions the <peer-id> should be used for the 'name' parameter. |
| | 95 | For the Avahi C API use the function |
| | 96 | ``avahi_entry_group_add_service()`` to establish the parent |
| | 97 | _bittorrent._tcp service and |
| | 98 | ``avahi_entry_group_add_service_subtype()`` with |
| | 99 | ``_<info-hash>._sub._bittorrent._tcp.`` as the 'type' parameter to |
| | 100 | establish the subservices. For both functions the <peer-id> should be |
| | 101 | used for the 'name' parameter. |
| 57 | | Clients will need to browse for _<info-hash>._sub._bittorrent._tcp in order to discover peers participating in the same torrent. Once again good documentation is provided on how to browse for zeroconf services in the above implementations. The replies will be in the form of <peer-id>._bittorrent._tcp. Note: Some Macintosh official bittorrent clients have a zeroconf implementation built in that publishes its services in the form of: |
| | 103 | Clients will need to browse for _<info-hash>._sub._bittorrent._tcp in |
| | 104 | order to discover peers participating in the same torrent. Once again |
| | 105 | good documentation is provided on how to browse for zeroconf services |
| | 106 | in the above implementations. The replies will be in the form of |
| | 107 | <peer-id>._bittorrent._tcp. Note: Some Macintosh official bittorrent |
| | 108 | clients have a zeroconf implementation built in that publishes its |
| | 109 | services in the form of: |
| 63 | | However this does not comply with RFC 2782 as the service name needs to be 14 characters or less in addition to the fact that it is not a service type but in fact a service instance it is advertising. Clients may choose to also browse for these services for backwards compatibility purposes (minimal effect - only one client is known to do this) however they should not publish in this format. |
| | 115 | However this does not comply with RFC 2782 as the service name needs |
| | 116 | to be 14 characters or less in addition to the fact that it is not a |
| | 117 | service type but in fact a service instance it is advertising. Clients |
| | 118 | may choose to also browse for these services for backwards |
| | 119 | compatibility purposes (minimal effect - only one client is known to |
| | 120 | do this) however they should not publish in this format. |
| 79 | | * I suspect the published peer-id need not be the hexed string as I have it now. A simple unique string may be all that is required (i.e. a hostname or a human readable computer name) with any uniqueness conflicts handled by zeroconf automatically. We ultimately only need to know what is on offer (as denoted by the info-hash) and where to get it (the resolved IP address). |
| | 138 | * I suspect the published peer-id need not be the hexed string as I |
| | 139 | have it now. A simple unique string may be all that is required |
| | 140 | (i.e. a hostname or a human readable computer name) with any |
| | 141 | uniqueness conflicts handled by zeroconf automatically. We |
| | 142 | ultimately only need to know what is on offer (as denoted by the |
| | 143 | info-hash) and where to get it (the resolved IP address). |
