I'm Remy Suen (you can just call me Rem), as some of you may know if you've been listening in on some of the past couple of ECF meeting conference calls. I am one of the three students that are working on ECF-related projects via Google's Summer of Code program. I'm writing a clean room implementation of the BitTorrent protocol and then creating a provider plug-in for ECF's file sharing APIs. I've got some issues I'd like to bring to the table in hopes that some of you would be able to help with.
1. How does one actually limit upload/download rates?
I've been poking away at a number of BitTorrent issues and features but have yet to start tackling this since I'm not even really sure how to start. Is it really just a matter of having a thread in the connection looking at past uploads and doing some kind of rolling average and then deciding how much data to write to the channel/socket in one second? This sounds like it could work (or not), but then now I have two threads per connection, which sounds like a lot, although I'm not sure if it really is. So any tips or hints on this would be most appreciated as I don't even know where to begin.
2. How will the org.eclipse.ecf.fileshare API fit in with BitTorrent, a bi-directional piece-sharing protocol?
The file sharing API is currently heavily biased towards unilateral file transportation services (rightfully so), which really leaves little API for me to use. I could certainly send IFileShareRetrieveDataEvents per block that I receive from a peer, but I can see that that getData() method isn't going to be really useful. Similar arguments could be had for IFileShareRetrieveStartEvent and its sending event counterparts. I guess what I'm trying to get at is that a BitTorrent provider for ECF is certainly doable (and I think I'm pretty close to having a simple one done, but the whole Namespace and ID concept seems awfully confusing to me), but just what kind of useful information can clients actually retrieve right now based on the current API?