-
Notifications
You must be signed in to change notification settings - Fork 1
Changes from the bittorrent spec
Traditional trackers take an IP and port from the peer, this is not feasible under webrtc.
The call flow for session establishment can be seen here. The key issue is that a sdp (session description protocol) string is one use only. In traditional trackers there is no limit to the times a peers IP and port can be distributed.
Thus, if a client wants 10 peers it must build 10 sdp offer strings and send them out.
The client now creates 10 offers and sends them to the server and they are distributed to peers that need more peers. The peers must now relay an "answer" to the client, until the client receives this message the connection is not established. This means the answer must be relayed via the server, adding additional incompatibility.
The essential concept of connecting peers based on the info_hash they are dealing with remains, I suggest removing the ip and port fields and replacing them with an "sdp" field, "offer" and "answer" will be additional events to send to the tracker.
Due to webrtc initiating on the web using UDP to connect to trackers is not (currently) an option. Websockets provide a suitable alternative, with a much lower overhead than HTTP and would allow for rapid communication of offers and answers (this would remove the announce period refresh also).
Compatibility is as simple as adding a webrtc-based tracker to the announce list, e.g: ws://opentracker.org/announce or wss://opentracker.org/announce for the secure version
Incompatible clients will ignore the tracker (even if they did connect, they would receive sdp instead of IP and port)
This means that the two tracker protocols can live side by side will very little issue.