RE: Advertisement Discovery Performance

<[email protected]> Fri, 9 Sep 2005 16:53:42 +0100
Newsgroups gmane.comp.java.jxta.user
Message-ID <5EAF119D9E35554484DB46D1AC1AFCD90294C181@i2km96-ukbr.domain1.systemhost.net>
No the getConnectedPeers will give you a list of PeerIDs

Now that you now PeerIDs - 
You can then use the DiscoveryService. getRemoteAdvertisements(peerID,
...

To get the Advertisements you are interested in


Stefan Maric | IT & Professional Services | BT Global Services | Phone: 
E: [email protected]  |  www.bt.com/globalservices 

-----Original Message-----
From: GEOFFREY DIX [mailto:[email protected]] 
Sent: Friday, September 09, 2005 4:32 PM
To: [email protected]
Subject: RE: [JXTA user] Advertisement Discovery Performance

Stefan,

Thanks for the response.  Since I am not searching for actual peers,
rather
their bidi pipe advs, will getConnectedPeers lead me to the peer's
pipe advertisement or would I have to add the pipe adv to the peer adv
to
retrieve that information?

Also, I do have RendezvousListener implemented (though It does not get
added
as a listener unless I cannot find another rdv in the group).  I will
have to
look into the rdv API docs more (code is at home, I am at work) and see
what
I can do to let it aid me in the discovery process.

Geoff

Quoting [email protected]:

> If you look at the net.jxta.rendezvous API
> 
> There is a getConnectedPeers() 
> Returns an Enumeration of PeerID of the peers that are currently
> connected
> 
> 
> You can also register as RendezvousListener using addListener()
> 
> As a RendezvousListener you must implement
> void rendezvousEvent(RendezvousEvent event)
> 
> 
> From the RendezvousEvent you can monitor client connections etc
> 
> 
> 
> So as your App initialises it should query the Rendevous to find out
who
> is already known and also establish a listener to be informed of new
> arrivals (and leavers etc)
> 
> 
> Stefan Maric | IT & Professional Services | BT Global Services |
Phone: 
> E: [email protected]  |  www.bt.com/globalservices 
> 
> 
> This electronic message contains information from British
> Telecommunications plc, which may be privileged 
> 
> or confidential.  The information is intended for use only by the
> individual(s) or entity named above.  If you 
> 
> are not the intended recipient, be aware that any disclosure, copying,
> distribution or use of the contents of 
> 
> this information is strictly prohibited.  If you have received this
> electronic message in error, please notify 
> 
> me by telephone or email (to the number or email address above)
> immediately.
> 
>  
> 
> Activity and use of the British Telecommunications plc e-mail system
is
> monitored to secure its effective 
> 
> operation and for other lawful business purposes. Communications using
> this system will also be monitored 
> 
> and may be recorded to secure effective operation and for other lawful
> business purposes.
> 
>  
> 
> British Telecommunications plc. Registered office:  81 Newgate Street
> London EC1A 7AJ   Registered in 
> 
> England no:  1800000
> 
> 
> -----Original Message-----
> From: GEOFFREY DIX [mailto:[email protected]] 
> Sent: Friday, September 09, 2005 2:49 PM
> To: [email protected]
> Subject: [JXTA user] Advertisement Discovery Performance
> 
> Hello,
> 
> I am currently trying to run performance tests on an application I
have
> written using the Java JXTA implementation (v 2.3.x).  I begin by
> starting
> up 12 peers on different nodes of a linux cluster.  Each peer creates
> and
> advertises a bidi pipe and all peers are members of the same group.  I
> discover the pipe advertisements by name (all advertisement names are
> built
> using <PeerGroupName>:<PeerName>) by making a call to
> getRemoteAdvertisements
> using 15 as the number of advertisements I would like to retrieve.  I
> wait
> about 10 seconds before sending the next getRemoteAdvertisements
request
> (I
> have tried many different combinations - 1sec, 30secs, 60 secs) to
give
> my
> discovery listener time to parse the advertisements and attempt to
> connect
> to the pipes.  Currently it takes about 5-10 minutes for all the peers
> to
> discover and connect to each other peer (though sometimes the
discovery
> does
> not succeed for all peers).  My problem (finally) is that since I am
> still
> in the process of making changes to my software baseline I would like
to
> find a way to improve the speed at which peers are discovered and
wonder
> if there is a more efficient method for discovery that I am not aware
> of?
> 
> Thanks in advance for any help/suggestions you can offer.
> 
> Geoff
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]