想搞清楚remotePublish可以看看这篇文章(考验英语水平的时间到了)

http://www.java.net/external?url=http://blogs.sun.com/bondolo/entry/don_t_rely_on_remotepublish

 

 

Don't Rely on remotePublish()

By bondolo on Apr 20, 2007

Since it's earliest versions the JXTA JSE API has included remotePublish() as part of the Discovery API. This is unfortunate because remotePublish() is frequently misused and it's not really that useful to begin with. Some JXTA users assume that advertisements must be remote published to another peer in order for the advertisement to be discovered. This is not true! Unless the advertisement needs to discoverable while the peer is unreachable or offline then local publication is almost always sufficient. Part of the confusion is undoubtably due to the presence of two methods, publish() and remotePublish(). In the JXTA JSE and JXTA-C APIs remotePublish() and publish() are separate APIs for implementation efficiency reasons only. You should consider advertisement publication as only one concept--the publish operation with an option for remote republication. Remote publication is intended to be only a means for easily requesting remote republication. In every case where remotePublish() is used it should be accompanied by appropriate local publication.

What remotePublish() does : send the provided advertisement to remote peers who may republish the advertisement locally. There a couple of big question marks that should arise from this statement.

• What is gained by having the other peers republish one of my advertisements?
• Which other peers will be receiving the advertisement?
• Will the peers which receive the advertisement accept my request and actually publish my advertisement?

Let's delve into these questions a little further.

Peers publish advertisements to allow other peers to discover their resources. Normally the advertisements published by a peer refer either directly or indirectly to that peer. Direct references to the publishing peer most commonly are it's PeerID but can also include the peer's name or other application specificidentifiers. Indirect references include the PipeIDs for pipes the peer is listening on or references to other advertisements that the peer has also published. Even more indirect references include descriptions of services that the publishing peer might be running.

For advertisements with direct references it is certainly best if the publishing peer itself is the responder when queries are made for the advertisement. Not only does this ensure that the querying peer receives the most recent version of the advertisement it also ensures that the querying peer receives only active advertisements. For queries which return multiple results having only the original publisher respond can also improve the relevance of responses since responses will be generated only by (and referring to) active peers.

For advertisements with indirect peer references it's less important that the originating peer be the peer that responds to queries for the advertisement, but the same advantages that apply for advertisements with direct references may still apply. This is particularly true for pipe advertisements. The peers which respond should be the peers which are listening on the pipe. In cases where the same advertisement applies to many peers, as is common for pipe advertisements, as long as one of the publishers responds then the query will be satisfied.

So what's gained by having your advertisement republished via remotePublish() by other peers and when is it useful? Remote republication does provide an additional (an usually unnecessary) source for your advertisement. It also may make your peer's advertisement available when your peer is not available. This may or may not be a benefit as it could result in other peers wasting time trying to contact your peer when it is unreachable.

Once you've decided that you want your advertisement republished by other peers you are still faced with two additional questions, "Which peers can I ask to republish my advertisement and will they do so?" There are no simple answers to these questions and the answers are not consistent. These questions are difficult to answer for many reasons not limited to; varying network topologies, varying network policies and peer autonomy. remotePublish() is a request you make to other peers on the network. There is no way to force the other peers to accept your request nor is there guarantee that any other peers are even listening.

In remotePublish()'s default form no particular peer is asked to perform the republication, any peer receiving the message is requested to republish the advertisement. Even when you designate a specific peer with remotePublish() it is not required to accept your advertisement. A peer may choose to ignore your request due to space limitations, a configured policy or any other reason and it will not inform your peer of it's refusal.

Assuming another peer does choose to accept your remotePublish() republication request the peer may not retain the advertisement for the entire time you requested. Peers often place tight limits on the total number of advertisements they are willing to republish or on the expiration time of advertisements received through remotePublish().

You may be wondering if there is any special interaction between remotePublish() and the RendezVous service. While it is true that in most network configurations a RendezVous peer is likely to receive all remotePublish() requests from it's client peers, RendezVous server peers do not offer any special republication privileges to their clients. All of the preceding restrictions still apply. In particular, the restrictions on advertisement expiration were added to JXTA implementations specifically to prevent RendezVous server peers from being flooded with long-lived bogus advertisements.

Here's a test we've made since 2002: "Does your application still work without remote publication?" Since even before JXTA JSE 2.0 we've considered making remote publish a "NO-OP" for some configurations, particularly ad hoc and relayed configurations. In ad hoc the remote republications all end up as very noisy and generally pointless multicast traffic. For relayed configurations removing remotePublish() would slightly reduce relay load. Since remotePublish() is occasionally useful and can sometimes slightly improve performance by reducing the number of hops a query must travel we've so far left it enabled. A properly written JXTA application shouldn't notice any significant changes if remotePublish() does nothing and in virtually every case the most reliable JXTA applications perform exactly the same with or without remotePublish().

Thanks to malveaux, DolF, HenrikGrosen and others for the excellent conversation, questions and insights (including this topic) over the last couple of weeks on the #jxta IRC channel.

Important Clarification : Some readers interpreted this entry as saying that remotePublish() is going to be removed or it's behaviour changed. There are no plans to change the way that remotePublish() works or to remove it, but readers should be careful in how they use remote publish and what they expect from it.