————————————————————————————————————————————————————————————————————
Offline Hello fellow JXTA users,
Recently, I had the opportunity to develop and commit a new service into the core JXSE API - the ContentService. Simply put, the ContentService is a service interface which can be used by a JXTA end user to transfer arbitrary data (Content) from one Peer to another. This new API is intended to eventually replace the existing (unused) Codat API as well as the CMS project.
So how does it work?
Content is shared by one peer which then provides access to an advertisement for that share. A remote peer becomes aware of this share advertisement (typically, but not necessarily, via the DiscoveryService) and can use the advertisement to initiate a transfer session to retrieve the remote data.
In addition to the basic functionality, the ContentService API was constructed to be pluggable and supports any number of ContentProvider implementations concurrently, each of which have the ability to support or ignore incoming API-based requests. It is the ContentProvider which performs the actual sharing and transfer of the content. This allows specific classes of data to be intelligently shared by a provider implementation which has in-depth knowledge of that class of data. The initial commit includes two very rudimentary implementations, one which is a trivial, TFTP-like implementation and another which leverages JxtaSockets. These implementations are intended to be replaced before too long with something more robust, scalable, and possibly standardized between the JXTA bindings.
In the event that this pluggable implementation is not desired, directly replacing the ContentService is also possible. Alternatively, all providers can be programmatically added/removed/accessed after the ContentService has been initialized and started, allowing the programmatic removal of dynamically added provider implementations (via, e.g., the Jar SPI mechanism).
Asynchronous updates relating to the status of the share/transfer are exposed programmatically via events. This includes events on the server-side relating to the active shares as well as events relating to client-side transfers in progress.
Perceived benefits of this work primarily consist of the following:
1) This work can be used for further improvements to the core JXTA loader mechanism, allowing for module implementations to be retrieved over JXTA-native transport in addition to the current HTTP support.
2) This also provides an easy, standard, and simply method to move data objects from one peer to another with minimal programmatic handling, lowering the bar for inexperienced JXTA developers.
Please take a walk through the API and let me know where it seems rough. Feedback (including/especially criticism) welcomed! For convenience, I've posted the javadoc at:
http://exoteric.bitknife.com/jxta/csapi/
Sample/tutorial code acting as a concrete example of how to use this API can be found at the following two URLs:
http://fisheye4.atlassian.com/browse/jxta-jxse/trunk/tutorials/src/tutor...
http://fisheye4.atlassian.com/browse/jxta-jxse/trunk/tutorials/src/tutor...
Enjoy...
- Login to post comments
- 132 visits
Offline Hi Wayne,
Thanks for taking a look at the new API. The more eyes on it, the better! :)
Great questions. Let me answer them one at a time:
> The startSourceLocation() method sounds like it
> searches for all potential remote source locations
> that are currently sharing that file. So how does
> that impact the startTransfer method which performs
> the actual transfer?
startSourceLocation() was provided to add the ability for an application to indicate that it was interested in a specific, advertised Content without actually transferring any data. Since finding remote sources can take some time, it could be useful to start the process early, then abort the unstarted transfer before significant bandwidth and/or disk space is brought into play. startTransfer() implicitly calls startSourceLocation() in the reference transfer implementations.
> Does startTransfer try to make
> use of multiple source locations to enable faster
> download of a file (kind of like BitTorrent)?
The API was built so that this would be possible but the reference implementations - there are currently 2 very basic provider implementations - currently only use a single source at a time, using multiple "locations" for fail-over purposes only. These more basic transfer providers were put in place to honor the requirement to be able to transport "dynamic" data in addition to "static" data, whereas the torrent-like transfers require the data to not change over time ("dynamic").
In the long run, a proper multi-sourced transfer provided should/would/could be provided to more elegantly and expediently move bits from multiple source locations to the destination peer.
> Or does
> it only access one source location for a file
> transfer?
As described above, only one at a time in the current provider implementations.
> Also what does the above comment mean when
> it states [i]start the transfer as soon as enough
> sources were found[/i]. Isn't one source location
> that is sharing the file enough to perform a
> transfer?
The API allows the transfer providers to define what is "enough" sources to start the actual transfer. In the existing 2 providers, one source is "enough", though the source location will continue until "many" potential sources are found, where "many" is also defined by the provider - the default being 5 in the 2 existing providers.
Thanks for giving the new API a kick in the tires! I highly encourage any feedback, particularly honest critiques of the API design, etc.. It's best to smooth out any known issues before we make the next official release and turn the API into stone!
Mike
Offline Hi Mike,
Thanks for your response. Your answers prompt more questions :).
I would like to pursue a multi-sourced transfer provider mainly because it would be interesting, will be needed by the JXTA community sooner or later, and I believe it would be a major test on how flexible and robust the ContentService API is. With that being said do you know of any ongoing current efforts or something in the works in developing a multi-sourced transfer provider? Does there exist any documentation (besides the reference implementations) for developing against the ContentService API? Being that multi-sourced transfer would rely on the fact that the content must remain static over time is there anything in the ContentService API that allows it to distinguish between static vs dynamic content so it can be intelligent enough to pick an appropriate transfer provider depending on the content type? Or I guess since the user has the ability to retrieve a particular content provider, this would be used in situations where a multi-source provider is preferred? I'm thinking out loud here and trying to envision where you have multiple providers that have different capabilities in respect to static and dynamic content :) !
Thanks!
-Wayne
Offline No problem, Wayne. Happy to help where I can!
> I would like to pursue a multi-sourced transfer
> provider mainly because it would be interesting, will
> be needed by the JXTA community sooner or later, and
> I believe it would be a major test on how flexible
> and robust the ContentService API is.
That would be great!
> With that being
> said do you know of any ongoing current efforts or
> something in the works in developing a multi-sourced
> transfer provider?
I know that hamada has developed a multi-peer transfer implementation and has considered placing it into open source. You may want to contact him to see where he's at with this. It was developed pre-ContentService, so I know that it doesn't fit directly into the new framework.
> Does there exist any documentation
> (besides the reference implementations) for
> developing against the ContentService API?
Not at present. :(
> Being that
> multi-sourced transfer would rely on the fact that
> the content must remain static over time is there
> anything in the ContentService API that allows it to
> distinguish between static vs dynamic content so it
> can be intelligent enough to pick an appropriate
> transfer provider depending on the content type?
Yes! The ContentID has a flag which you can set/examine to determine whether content is static or dymanic. Additionally, each provider presents it's own ContentAdvertisement to the API user when it is asked to share Content. This advertisement can contain any information your provider would need to implement the transfer. Transfer implementations which extend the AbstractContentTransfer will inherit some ability to filter advertisements based on what type they are and what they contain. Beware though - the AbstractContentTransfer class gets a bit ugly in places. It needs a bit of love. Specifically, I'd like to abstract the Content location code out and clean up some of the locking but have just run out of cycles... :)
> Or I
> guess since the user has the ability to retrieve a
> particular content provider, this would be used in
> situations where a multi-source provider is
> preferred?
To provide the most robust behavior, if a peer is faced with multiple providers which can retrieve the same content, the providers will be used at random. You can programmatically restrict this should you wish to do so, however.
> I'm thinking out loud here and trying to
> envision where you have multiple providers that have
> different capabilities in respect to static and
> dynamic content :) !
>
> Thanks!
Have fun digging into this. I'm going to be away from my machine for a while so I'll probably be slow to respond over the next couple of weeks. I'll try to check in as often as I can to be of help.
Enjoy,
Mike
Offline It is a big contribution, thanks !!!
J.
Hi mcumings,
I've had the opportunity to look at the ContentService API because I'm looking to integrate content sharing capability into my project. I thought this was a very elegant and powerful API that you developed and was exactly what I was looking for in a content service API. When I was going through the sample Client code a noticed a few things that caught my interest:
/*
198 * This step is not required but is here to illustrate the
199 * possibility. This advises the ContentProviders to
200 * try to find places to retrieve the Content from but will
201 * not actually start transferring data. We'll sleep after
202 * we initiate source location to allow this to proceed
203 * outwith actual retrieval attempts.
204 */
205 System.out.println("Starting source location");
206 transfer.startSourceLocation();
207 System.out.println("Waiting for 5 seconds to demonstrate source location...");
208 Thread.sleep(5000);
209
210 /*
211 * Now we'll start the transfer in earnest. If we had chosen
212 * not to explicitly request source location as we did above,
213 * this would implicitly locate sources and start the transfer
214 * as soon as enough sources were found.
215 */
216 transfer.startTransfer(new File("content"));
The startSourceLocation() method sounds like it searches for all potential remote source locations that are currently sharing that file. So how does that impact the startTransfer method which performs the actual transfer? Does startTransfer try to make use of multiple source locations to enable faster download of a file (kind of like BitTorrent)? Or does it only access one source location for a file transfer? Also what does the above comment mean when it states [i]start the transfer as soon as enough sources were found[/i]. Isn't one source location that is sharing the file enough to perform a transfer?
Thanks!
-Wayne