TODO: Now: * The administration of overlay connections is broken. Sometimes the secure overlay things there is no connection and calls connectPeer() but the OverlayEncoder still thinks it has a connection and reuses that. I temporarily disabled the OverlayEncoder reusing existing connections. * In r529 there was a problem when a single Windows client would connect to our text-based seeder (i.e. btlaunchmany) with no other clients present. Apparently both the seeder and client would connect to eachother simultaneously, but not end up with a good connection, halting the client. Arno, 2006-02-20: It appears to have disappeared in r611. * When using btlaunchmany for seeding, it does not always reuse the pickled Merkle trees stored in /datacache. Arno, 2006-02-20: Only press Ctrl-C once, and then let it shutdown properly appears to solve this. * Buddycast doesn't attempt to contact any superpeers. Alternative is to disable super-peer bootstrapping and just let it talk to the peers it meets. I currently do the latter. Could use example torrent file to meet other Tribesmen. Arno, 2006-02-20: I think this works now? * Text version may not work as before because I hacked up launchmanycore.py and BitTornado/launchmanycore.py. Need to redo this. Arno, 2006-1-6: A single friends-assisted download with 1 helper in passive mode appears to work, so it's not that broken. Arno, 2006-2-2: The code changed radically since last entry, but the ./btlaunchmany.py works now as seeder. * Start two clients, each with busy torrent (i.e., many peers) and then asking each to help the other. The DOWNLOAD_HELP requests may not get through. Fix this. Arno, 2006-2-7: There were was a concurrency problem between the MainThread and the network thread in the RawServer class. The MainThread via the DL helper GUI would add tasks to the rawserver, while the rawserver would be moving the external task queue to its internal queue. So there may be improvement. * There is a potential concurrency problem between the GUI thread (MainThread) and the network thread (ABCLaunchMany) thread. They both write to the peer DB, e.g. when a user edits the friends list and there is a torrent downloading. Short term: * Tribler/Worldmap/ipinfo's lookupIPInfo will now timeout after 1 second to prevent it from holding up the RawServer. (I scheduled the lookups as tasks on the rawserver, but they sometimes take too long, freezing up all network traffic). A better solution is to do IP lookup on a separate thread. Arno, 2006-02-21: I now use Timer()s to fix this problem. * Also: make sure that earth map is updated while people are watching it. * If user is already downloading the torrent when asked to help by a friend the former user gets an unclear popup saying the torrent already exists. Make clearer. * Convert TorrentMaker/btmaketorrentgui to use "safeguiupdate.py" classes. * Preferences: option to clear databases. * Put text in Tribler/Dialogs/*.py in lang file. * We now have *unauthenticated* PermID to the detail window's list of peers (i.e., spewList). This will need to be replaced with authenticated PermIDs in the future. The problem that linking a random connection to a PermID established via a different (overlay) connection in a secure way is nearly or definitely impossible. * Store found lat/long info in PeerDB. * Change GET_METADATA/METADATA messages to operate on lists rather than single torrents. Arno, 2006-1-31: Jie said he would do this. * Complete the specification of the PREF_EXCHANGE and GET_METADATA messages to a level that others could implement a compatible version. * Question: Should we change the Recommendation design to prevent accusations of being spyware and and violating privacy? I.e. make sure a) no data is stored at our superpeer servers b) preference exchange takes place between explicitly defined friends. So a friend gives you (PermID, IP address, port) with you register in your client, and you only exchange preferences with that friend. These things are not necessary in a system where all content distributed is legal, but as that is not the case for BitTorrent we may have to accommodate for that. Proposed solution: At first startup the user will be asked if he wants to: 1. Share list of downloaded torrents with everybody 2. Share list of downloaded torrents with friends only 3. Share list of downloaded torrents with noone. * Website/bug reporting facility for Chitraka. Proposal by Johan: for first period use ABC mailing list * In the current design, after a PREFERENCE_EXCHANGE message, the receiver will directly ask the sender for the metadata of any files it did not know. I.e. it will send a GET_METADATA message and receive all the torrents for the unknown files in a METADATA reply. This works when the .torrent files are small Merkle torrents, but can consume a lot of bandwidth if the .torrents are regular torrents containing a hash for each piece. Question is if we should add extra support to reduce the amount of bandwidth consumed when old torrents are used. E.g. don't ask torrents for all files, just files that are likely to be liked by the user. Or delay obtaining the metadata until the user actually says he wants to download the file. Proposal is to write a design note for this issue, giving pros and cons for each alternative (including ignoring the issue) Longer term: * Clearly define what all the planned features for BitTorrent++ and BitTorrent-2 are. Currently they are 1/2 line bullets on a PowerPoint sheet * Design an encoding for a Merkle torrent in a URL of less that 2083 bytes. DONE: * Write a design note about protocol versioning. In particular, it should have support for protocol compatibility. E.g. if the protocol has been upgraded to V2, but a V2 client can still talk to a V1 client and vice versa, this should be possible. DONE, Arno, 11-11-2005 * Replace Challenge/Response with std. protocol as suggested by Jeroen Doumen (ISO/IEC 9798-3 protocol, see $10.3.3 (ii) in Handbook of Applied Crypto) DONE, Arno, 14-11-2005 [ ] OPEN ISSUE: We currently authenticate only the overlay-swarm connection and not the normal BT connection. At present there is no secure correlation between the two TCP connections, so we cannot authenticate/ allow priviledged operations over the normal BT connection. * Update the Challenge/Response specification to reflect changes in CHALLENGE message. OUTDATED by upgrade of C/R protocol, Arno 14-11-2005 * Implement PREFERENCE_EXCHANGE and GET_METADATA messages DONE, Jie * Implement BuddyCast algorithm DONE, Jie * Migrate/implement Pawel's download-via-friends to ABC. DONE, Pawel, Arno * Automatic seeding don't work when creating torrents for each file in a given directory. Should update btmaketorrentgui.py's done() method such that it registers all created torrents. DONE, Arno * I don't think there is an authentication check that sees if sender of DOWNLOAD_HELP is actually a friend. * Add support for stopping download help * Helping client's GUI doesn't repaint correctly. * List of helpers selected must be made persistent somehow Arno, 2006-1-27: No, currently I prefer a transient approach. * Opening detail frame doesn't work when torrent stopped. * Remove peerID field from RESERVE_PIECES * The coordinator sends DOWNLOAD_HELP over a overlay swarm connection. The helper then initiates a separate control connection for reserving pieces. Is this connection authenticated? If not: DoS attack possible by malicious host reserving all pieces but not delivering (TRUE?) And why is this needed. Overlay connection can also be used, IMHO. Arno, 2006-1-31: all sensitive messages are now sent over the overlay connection. * Move 'bsddb' to $HOME/.ABC/ such that all user data is stored there. * Extend Preferences with flags for enabling/disabling Download Help and Recommendation. * Problem when doing download help: after request the requested user's name changes to "unknown" in the database ??? * All peers are added as friends, see BitTorrent/cachedb:PeerTable::addPeer as the addFriend method doesn't seem to work. * Need way/GUI to add friends. Currently list of friends hardcoded into abc.py * Read friends.txt from $HOME/.ABC if it stays. * Integrate friends management with peer list. * cities.txt should be empty or contain a sensible list of cities. Arno, 2006-02-20: Empty.