Re: MyJXTA configuration

Also, Volker contributed an ext:config/ui library that should allow one to graphically
maniuplate the underlying ext:config profile. We need to turn that on w/in MyJXTA, for
obvious reasons. Note that you will have to restart your instance post reconfig but at
least it does provide a more user friendly means of config management.

We will also likely add the ext:config/ui elements to the emerbing "preferences" work
that is underway which in turn will allow one to further specialize MyJXTA.

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 


James Todd wrote:
> 
> 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]
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>