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

1、想搞清楚remotepublish可以看看这篇文章(考验英语水平的时间到了 don't rely on remotepublish() by bondolo on apr 20, 2007 sie it's earliest versions the jxta jse api has includ remotepublish() as part of the discovery api. this is unfortunate because remotepublish() is frequently misu and it's not really that usef

2、ul 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! un the advertisement needs to discoverable while the peer is unreachable or offline then local publiion is almost always sufficient

3、. part of the confusion is undoubtably e 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 conser advertisement publication as only one concept-the publ

4、ish 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 ad

5、vertisement to remote peers may republish the advertisement locally. there a couple of big question marks that should arise from this ement. what is gained by having the other peers republish one of my advertisements?which other peers will be receiving the advertisement?will the peers receive the ad

6、vertisement 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. noally the advertisements published by a peer refer either directly or indirectly to that peer. d

7、irect references to the publishing peer most commonly are it's peerid but can ao 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

8、. even 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 queryin

9、g 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

10、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 i

11、s 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

12、what's gained by having your advertisement republished via remotepublish() by other peers and when is it useful? remote republication does provide an aitional (an usually unnecessary) source for your advertisement. it also may make your peer's advertisement available when your peer is not av

13、ailable. this may or may not be a benefit as it could result in other peers wasting 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 t

14、o 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 icult to answer for many reasons not limited to; varying network topologies, varying network policies and peer autonomy. remotepublish() is a

15、 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 guaran 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

16、 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 i

17、t'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

18、 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'

19、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 fr

20、om 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, particul

21、arly 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 d. a properly written jxta applicati