[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] File sharing inquiries...
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Thu, 13 Jul 2006 21:09:27 -0700
- Delivered-to: email@example.com
- User-agent: Thunderbird 22.214.171.124 (Windows/20060516)
Remy Suen wrote:
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.
For the filesharing API, some specification of upload/download rates
could be added to the API to allow providers (like Bittorrent) that
support such features to expose them to clients on an individual file
level (I assume BT supports setting rates at the level of individual
files...either before or during file retrieval).
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?
Not very much...basically just the contents of the file itself. But my
intention with the fileshare API was to expose other methods (on either
the IFileShareContainer, IFileShareRetrieveConfig, or IFileShare) OR add
adapter interfaces via IAdaptable for categories of API like rate
control, statistics gathering, etc. Also new event types can easily be
created added for handling asynch responses to requests.
So what I would like to do is to have Remy propose a desired set of
features (e.g. rate control) and then we can propose an
enchancement/generalization of the file share API to support.
RE: the namespace/ID concept...the notion is have some sort of
structured and extensible way to represent addressing information (other
than just String or URI). The ECF namespace extension point allows ECF
providers to create their own types of IDs...with whatever structure
they require to refer to a remote service, file, user, etc. e.g.
There's a little more available here:
But as usual more is needed.