[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[ecf-dev] Re: File sharing inquiries...
|
Hi everyone,
Here are some changes/suggestions to the file sharing API that I'm
sending to the dev list for public criqitue. Scott and I went over a
few of these together but some points are my own which I did not bring
up to him as I felt some other points were more important.
----------------------------
org.eclipse.ecf.fileshare.events.IFileShareRetrieveDataEvent
This interface offers a getData() method which returns a byte[] with
the data that has been retrieved. The usefulness of this method is
questionable as raw bytes are rather useless to most client developers
and a sub-chunk of a file's entire chunk is even more useless. This
gives the developer the impression that the file that is being
retrieved needs to be written by the client application itself, which
may have been the original intent?
This is extremely low level and ought to be hidden from view in my
opinion, when you invoke the start() method in
org.eclipse.ecf.fileshare.IFileShare, the transfer begins, and the
file should be saved and completed when the
org.eclipse.ecf.fileshare.events.IFileShareRetrieveCompleteEvent event
has been fired, as can seen, there should be minimal human intervention.
A more useful method that could be offered by this event may be to
return a long which indicates how much data was read, for progress
reasons, or a double, which would display progress easily just be
returning 0.5 or 50.0 for 50% (we would have to specify the form
explicitly in the javadoc to prevent confusions and to ensure
consistency).
The same argument could probably be had for
org.eclipse.ecf.fileshare.events.IFileShareSendDataEvent, after all,
retrieving the amount of data that is sent is essentially for
statistics gathering, to check up on just how much more there is to
go.
----------------------------
For pausing and resuming of downloads and uploads, Scott suggested an
IPausable adapter, which sounds like a workable solution to me. I'm
not familiar with how most IM protocols exchange files but I know for
a fact that AIM/ICQ supports resume (or, it once did anyway), I don't
think it's likely that only a few select protocols supports pausing
and resuming as its a rather crucial feature for file exchange, so
actually having it exposed as part of the API will be useful for
client developers.
----------------------------
Scott also suggested an IFileShareRetrieverController yesterday for
speed capping, although IFileShareController or a more specific name
may be more appropriate as users would wish to cap speeds both when
they're sending or retrieving files. It's questionable as to what
other things can be controlled, which is why I'm suggesting that a
more specific name may be more appropriate, like
IFileShareSpeedController maybe? Then again, perhaps it's better to
think ahead and to just use a more generic name so that other features
can be added to the API later?
File selection, whilst an important feature in BitTorrent, is
essentially non-existent in other file sharing protocols since all the
other ones (that I know of) merely transfers one file at a time, so it
is rather pointless to add another adapter interface (if that's what
they're called) just to support one protocol. So this is unlikely
going to make it into this "controller interface".
----------------------------
For statistics gathering, a user would be interested in his or her
download speed, upload speed, and the time remaining for the transfer
to complete. I'm currently questioning whether it's more useful for it
to be a method in org.eclipse.ecf.fileshare.IFileShare or whether an
event should be fired instead.
As the event would be fired extremely frequently, I think most
implementors will probably just add a thread that goes on a one second
loop or something and just constantly fire off the event (this may not
apply for download/upload speeds if the developer of the provider
decides to compare rates and only fire an event if it has changed, but
the "time remaining" statistic is pretty much guaranteed to be fired
every second unless when your up/down rate is zero, which in that case
it stays at infinity, but that's an exception case we should ignore I
think). The only difference, I suppose, is that using an event removes
the need for the client developers to have to run a thread themselves
to check for values, which is nice, but it still seems kind of weird
to use an event for these types of statistics. I could be wrong, so
comments are definitely welcome.
----------------------------
If you've read this far, I commend you, this was really rather long,
my apologies. :(
Regards,
Rem
On 7/14/06, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi Rem,
Remy Suen wrote:
> Hi everyone,
>
> 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.
ecf.provider.bt://slewis@localhost/path/to/filename.bt
or
http://www.eclipse.org/file.txt
or
ecftcp://ecf.eclipse.org:3282/server
There's a little more available here:
http://www.eclipse.org/ecf/documentation.html#Identity
But as usual more is needed.
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
