Re: MyJXTA configuration

The "My MyJXTA" blog entry is still relevant:

  http://weblogs.java.net/blog/gonzo/archive/2005/02/my_myjxta.html

The only possible change to that article would be, as Paul has mentioned,
turn Multicast on as it is off by default. This will enable peers on local
subnets to be able to readily find one another.

MyJXTA is constructed to "auto provision rdv services" on a 120s cycle, that
meaning that upon joining an application group (one that is not NetPeerGroup)
it will seek a rdv lease (become a rdv client) and after said period of time
if a lease can not be obtained then it will promote itself to a rdv proper.
This allows subsequent peers joining the group to rely on the afore mentioned
instance as it's rdv until it resigns from the group, at which point the cycle
repeats.

In practice, on the PubNet, there is typicaly a peer or 2 hanging out in the
root application group, namely MyJXTA. As such, they typically find one another
readily and all is good. When running MyJXTA in isolation, as you are trying to
do and I very much encourage you to continue trying, there is the problem of
not enough peers participating to create this balance. ie the eco-system is
frail.

As response to a series of concerns, affectionately known as "uber task:"

  http://myjxta2.jxta.org/issues/show_bug.cgi?id=289

For the topic of more readily "connecting," read "finding rdvs to obtain a lease,"
we now become a rdv in 3s upon "creating" a group from w/in MyJXTA. This is not true
for the MyJXTA "root group" named MyJXTA. For joining groups, I would like to add a
little "group management" dialog whereby one can tune/vary the "auto start/rdv"
parameter as needed, remaining at 120s by default. Once this is in place, one can
optionally adjust the value, join said groups and more aggressively (or not) provision
rdv services.

  note: I would like to call the underlying autstart(...) method directly at any time,
        eg current group, but it looks to be coded such that it will wait the predetermined
        value, the value as set when joining the group, before waking up and taking the
        new value into consideration. If we could interupt that timer and adjust the
        current sleep/wait time that would be optimal.

So, all things taken into consideration, the blog is your best bet, consider starting up
the JXTA Shell (file->prefs->shell), enter the command "rdvstatus" and wait the default
120s to see if you and your colleagues can connect. On average and once your deployment
"normalizes," ie a peer or 2 is always hanging out, you will find this wait time is not
as much a burdeon as it feels now during initial testing, or so I suspect.

The "bootstrap" value is simply a URI that in turn includes addresses of well known/established
Rdv and/or Relay peers. This is how applications seed initial context from the PubNet, for
example.

A number of MyJXTA knowledgeable folks hang out on MyJXTA and are available to help with
these types of questsions "real time."

hth,

- james

--
James Todd :: blogs.sun.com/gonzo | weblogs.java.net/blog/gonzo 

MyJXTA :: use it - learn it - do it

Java == platform independence
XML  == application independence
JXTA == network independence

Secure End-to-End Computing 


Poole, Paul P1 wrote:
> Joerg,
> 
> The file you want to edit is Profile.xml
> 
> If you are working with the latest code from cvs, use this:
>   <network>
>     <rendezVous discovery="false">
>       <address>//:</address>
>     </rendezVous>
> 
>     <relays discovery="false">
>       <address>//:</address>
>     </relays>
>   </network>
> 
> I am not sure how this differs from boostrap="" -- James?
> 
> Also, I have found that you will have no success finding other peers
> unless you turn multicasting on.  For me, this is not desireable, so I
> am working on a solution.  My thought had been that in an isolated
> network of a few peers if no rendezvous existed, one of the peers
> (probably the first to enter the network) would automatically become a
> rendezvous and the network would establish itself.  This has turned out
> to either not be true, or I need to continue to work on my
> configuration.
> 
> Hth.
> 
> Paul
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: Wednesday, July 27, 2005 10:17 AM
> To: [email protected]
> Subject: Re: [JXTA user] MyJXTA configuration
> 
> 
> Hey James,
> 
> you wrote to Paul on July 20th:
> 
>>Next up, the MyJXTA configuration file myjxta.xml, which happens to be
> 
> 
>>an
>>ext:config profile extension (more on that in a bit), supports the
> 
> notion of
> 
>> "Network IDs and optional descriptors" which are in turn used by
> 
> MyJXTA 
> 
>>proper to effectively create the respective "config.properties" file
> 
> that is 
> 
>>hosted in the MyJXTA JXTA_HOME, which is by default ~/.myjxta.
>>
>>Now, to explain the "bootstrap" info a bit more, you can safely "null"
> 
> 
>>the
>>defaults out as follows:
>>
>><rendezvous bootstrap="" discovery="false"> ... <relays bootstrap=""
>>discovery="false">...
>>
>>so as to prevent association with the PubNet, which is wired in for 
>>the
>>default "edge" profile, with MyJXTA serving as a prototypical edge
> 
> reference 
> 
>>application. The end result should work great for 2 or more peers to
> 
> connect
> 
>>on the same subnet.
> 
> 
> As I also want to set up a local MyJXTA subnet I tried to apply your
> described changes. Problem is, there are no <rendezvous> or <relay> tags
> in my myjxta.xml.
> 
> To reach above described behavior should I simply append those tags in
> myjxta.xml or should the changes be made in another xml file?
> profile.xml could be a candidate but there is no attribute "bootstrap"
> in the <rendezvous> and <relay> tags, only attribute "discovery". So
> when you write one should "null" the defaults, shall I add the bootstrap
> attribute in profile.xml?
> 
> And by the way as no URL or IP is found in here how does MyJXTA find
> seeding rendezvous at all? Are their addresses hardcoded in the source?
> 
> thx
> Joerg
> 
> ---------------------------------------------------------------------
> 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]
>