ext:config addition (was: Re: [JXTA dev] ext:config for cluster setup)

In a nutshell ...

> If you simply leave the rendezvous addresses blank, the default 
> bootstrap address will be used to discover rendezvous from the public 
> network. Explicitly nulling it out seems the only way to make sure your 
> peer doesn't try to find or connect to any rendezvous. In the case of 
> relays, the simple nulling out doesn't work (I think James has 
> identified this as a bug in the config package), so you can give it a 
> bogus URI instead.

the ext:config library does not include a "don't use relay" checkbox like the
classic configurator (that is displayed w/ Shell). ext:config is designed with
both minimalism and data normalization in mind ... and disabling "use relay"
or "use rdv" for that matter is, IMHO, superfluous data, data that we should
be able to infer. Well, having mulled this over and forced to think about
Profile.SUPER for a bit, given I don't run any systems under ext:config Profile.SUPER
yet, I think I was wrong. Good news is that adding datum is far easier then
moving about data or removing it. So ...

What if we added an "enabled" attribute to /jxta/network/[rendezVous,relays]@enabled?

The default might be "true" so as to represent the common use case of Profile.EDGE
but one could specify false for isolated super and/or local profiles.

This is sounding like the right fix to me, having thought this through a bit on
the lists (thx Vanessa) et al.

What say you?

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 


Vanessa Williams wrote:
> 
> On 26-Jul-05, at 6:08 AM, Sven Schulz wrote:
> 
>> Using role profiles in conjunction with XSLT would be a great feature.
>>
>> For now, I have another question on rendezvous peer configuration. As I
>> explained already, I would like to establish a private network within the
>> cluster. Therefore I have to setup my own rendezvous peer (right?). Do I
>> have to have my own relay peer? No, I suppose since there are no network
>> segementations to bridge within a cluster, right?
>>
>> Okay, may someone post a valid profile for rendezvous? Mine refuses to 
>> work.
>> Have a look at it:
>>
> 
> I'm trying to do the same thing: set up a rendezvous in a private 
> network. Although it *appears* to be working, I haven't been able to 
> configure a client to connect to it properly, so it may still be broken. 
> Nonetheless, I think I might have a few usable comments on the profile 
> below. See comments inline below.
> 
> 
>> <?xml version="1.0" encoding="utf-8" standalone="no"?>
>> <!DOCTYPE org.jxta:configuration>
>> <!-- A JXTA profile defining a TCP-only super peer configuration. -->
>> <jxta>
>>   <network>
>>     <rendezVous bootstrap="" discovery="false">
>>       <address>tcp://192.168.0.120:9700</address>
>>     </rendezVous>
>>     <relays bootstrap="" discovery="false">
>>       <address>tcp://192.168.0.120:9700</address>
>>     </relays>
>>   </network>
>>   <peer descriptor="private super peer"/>
>>   <transport>
>>     <tcp enabled="true">
>>       <address range="100">
>>         <multicast enabled="false"/>
>>       </address>
>>     </tcp>
>>     <http enabled="false"/>
>>   </transport>
>>   <service>
>>     <rendezVous enabled="true"/>
>>     <relay enabled="true">
>>       <incoming enabled="true"/>
>>       <outgoing enabled="true"/>
>>     </relay>
>>   </service>
>> </jxta>
>>
>> There are several points I am confused about.
>>
>> (1) In the network section. Do I have to configure a rendezvous, even 
>> if I
>> know that the peer to configured with the profile is the only rendezvous
>> within my network? If not, how is it done? Currently the given address is
>> the address of the peer itself. I think this might be incorrect.
>>
> 
> No, I don't think that you do. Over on the users list, James and I have 
> been discussing this situation. The current working solution seems to 
> look something like:
> 
>   <network>
>     <rendezVous bootstrap=""/>
>     <relays bootstrap="file:///tmp/bogus.txt"/>
>   </network>
> 
> If you simply leave the rendezvous addresses blank, the default 
> bootstrap address will be used to discover rendezvous from the public 
> network. Explicitly nulling it out seems the only way to make sure your 
> peer doesn't try to find or connect to any rendezvous. In the case of 
> relays, the simple nulling out doesn't work (I think James has 
> identified this as a bug in the config package), so you can give it a 
> bogus URI instead.
> 
>> (2) Do I have to explicitely disable HTTP, if I don't want to have it 
>> as a
>> transport?
>>
> 
> Yes. That's my understanding, anyway.
> 
> 
>> (3) With the given profile, the configuration GUI pops up, when the 
>> peer is
>> started. Why?
> 
> 
> This happens to me when the configuration is not complete somehow. 
> Looking through the GUI panes to see what's not set properly should give 
> you a clue as to what's missing. Or it may be unhappy about the 
> rendezvous configuration. I notice that in the transport section you 
> haven't provided any addresses at all. Not even port numbers. I'm not 
> sure what will happen if you do that.
> 
> 
>>
>> (4) I get debug messages stating some address confusion
>>
>> pool-1-thread-1 DEBUG config.Configurator - can't get root cert
>> pool-1-thread-1 DEBUG config.Configurator - address scheme 
>> incompatibility
>> pool-1-thread-1 DEBUG config.Configurator - address and public address
>> scheme incompatibility
>>
>> What these entries are about?
>>
> 
> Unfortunately the configurator error messages don't indicate where the 
> problems were encountered, so you have to guess. I'd guess that the lack 
> of any transport addresses could be a problem. The root cert one might 
> be unimportant. I'd try getting rid of the other two first.
> 
> hth,
> 
> Vanessa
> 
>> Thanks in advance,
>> Sven
>>
>>
>>
>>> --- Ursprüngliche Nachricht ---
>>> Von: James Todd <[email protected]>
>>> An: [email protected]
>>> Betreff: Re: [JXTA dev] ext:config for cluster setup
>>> Datum: Mon, 18 Jul 2005 13:15:15 -0700
>>>
>>>
>>> Re ext:config transforms:
>>>
>>>>  Re cluster management and ext:config, and this is something we should
>>>> try out with JDF (http://jdf.jxta.org)
>>>>  as it currently uses an earlier version of ext:config and is a
>>>> prototypical cluster app. I suspect the
>>>>  best way to support cluster config and deployment from an ext:config
>>>> perspective is to rely on XSLT
>>>>  (transforms) and possibly some XLink (note: I could very well 
>>>> likely be
>>>> dated on the later). This way,
>>>>  one could provide a small handful of very general profiles, ie "role
>>>> profiles" and run them through
>>>>  late binding transforms to inline the specific addressing data as a
>>>> late binding data point. I suspect
>>>>  Alex will have ideas on this as well.
>>>
>>>
>>> Alex and I have been talking about adding an XSLT argument to Profile so
>>> that this
>>> binding will occur at Profile instantiation time, which is typically the
>>> first step
>>> to creating an ext:config Configurator. Something like:
>>>
>>>   Profile(InputStream is);
>>>   Profile(InputStream is, ?InputStream style?);
>>>   Profile(URL u);
>>>   Profile(URL u, ?URL style?);
>>>
>>> This work is on the short list and I believe a significant enabler for
>>> JXTA configuration
>>> specialization, eg cluster management. The beauty of this is that the
>>> transform is handled
>>> outside ext:config proper.
>>>
>>> In any event, this item is on the ext:config short list as well but, 
>>> IMHO,
>>> requires JRE 1.5
>>> which includes better native (read no additional jars required) XML
>>> support.
>>>
>>> So, if you are interested in this feature feel free to dial in. 
>>> Expressing
>>> your vote for
>>> migrating to JRE 1.5 will help as well.
>>>
>>> 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:
>>>
>>>>
>>>> Hey Sven -
>>>>
>>>>  For private networks you should override the default bootstrap (aka
>>>> seeding) address:
>>>>
>>>>  <network>     <rendezVous bootstrap="" discovery="false">
>>>>        <address>tcp://192.168.0.120</address>
>>>>    </rendezVous>
>>>>    <relays bootstrap="" discovery="false">
>>>>        <address>tcp://192.168.0.120</address>
>>>>    </relays>
>>>>  </network>
>>>>
>>>>  If you have a bootstrap service, then you can specify the 
>>>> corresponding
>>>> URI as a bootstrap, eg:
>>>>
>>>>  <network>     <rendezVous bootstrap="file:///tmp/rdv.txt"
>>>> discovery="false">
>>>>        <address>tcp://192.168.0.120</address>
>>>>    </rendezVous>
>>>>    <relays bootstrap="file:///tmp/rly.txt" discovery="false">
>>>>        <address>tcp://192.168.0.120</address>
>>>>    </relays>
>>>>  </network>
>>>>
>>>>  note: the bootstrap (aka seeding) field will migrate to an element
>>>> shortly as there can be zero or
>>>>        more bootstrap addresses
>>>>
>>>>  The "address macro" does a couple of things. For remote addresses it
>>>> let's one filter from the
>>>>  list (eg bootstrap) addresses that meet it's overlay criteria, eg:
>>>>
>>>>    bootstrap results: http://a:9700 and tcp://a:9701
>>>>
>>>>  A macro of "tcp://" will/should retain only the address "tcp://a:9701"
>>>>
>>>>  These filters are used in the TCP and HTTP profiles, ie there is *no*
>>>> logic outside of the profile
>>>>  and the included macros to support these specialized profiles.
>>>> Admittedly the above can be viewed
>>>>  as overkill at the worse or a boundary condition at the best. There 
>>>> are
>>>> some deployments that are
>>>>  intereted in TCP only, thus the macro support.
>>>>
>>>>  But, for local resources the macros are critical.
>>>>
>>>>  For local resources, eg transports, the macro is used to specify parts
>>>> of the address while ignoring
>>>>  some other parts. Specifically this was important so that one could
>>>> leverage the ANY/ALL address yet
>>>>  specify a non-default port, eg:
>>>>
>>>>    <address range="100">http://:9700</address>
>>>>
>>>>  Re cluster management and ext:config, and this is something we should
>>>> try out with JDF (http://jdf.jxta.org)
>>>>  as it currently uses an earlier version of ext:config and is a
>>>> prototypical cluster app. I suspect the
>>>>  best way to support cluster config and deployment from an ext:config
>>>> perspective is to rely on XSLT
>>>>  (transforms) and possibly some XLink (note: I could very well 
>>>> likely be
>>>> dated on the later). This way,
>>>>  one could provide a small handful of very general profiles, ie "role
>>>> profiles" and run them through
>>>>  late binding transforms to inline the specific addressing data as a
>>>> late binding data point. I suspect
>>>>  Alex will have ideas on this as well.
>>>>
>>>>  Lastly, didn't you request a "config lifecycle" request awhile 
>>>> back? If
>>>> so, I'm generating an ext:config
>>>>  short list of interesting features to consider so now would likely 
>>>> be a
>>>> great time to throw the idea into
>>>>  the hopper. For my part, much of the mods I'm proposing are
>>>> refactorings from MyJXTA that have been
>>>>  extremely useful for my work, eg: private network deployment,
>>>> declarative resource generation, etc.
>>>>
>>>>  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
>>>>
>>>>
>>>> Sven Schulz wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I want to setup sixteen cluster nodes to run a distributed computation
>>>>> based
>>>>> on a JXTA substrate. Since there is absolutely no access to the
>>>>> Internet I
>>>>> have to setup my own infrastructure (Relay / Rendezvous). I have my 
>>>>> own
>>>>> config.properties to define a private NetPeerGroup.
>>>>>
>>>>> Having spent lots of hours trying to deploy such a setup, I hope that
>>>>> someone on this list may help me with my issues!
>>>>>
>>>>> I've varied each and every parameter, each time ending up with invalid
>>>>> configurations. I'm not sure how this nifty little 'address macro
>>>>> expansion'
>>>>> thing (as mentioned in the Wiki) works? I think it is used to get
>>>>> something
>>>>> meaningful from expressions like 'tcp://:9700'. But how it is done
>>>>> exactly
>>>>> and what is the correct syntax? Where can it be applied?
>>>>>
>>>>> Here is my configuration:
>>>>>
>>>>> 1 x Superpeer configured by reading the following profile (copied from
>>>>> predefined super.xml)
>>>>>
>>>>> <?xml version="1.0" encoding="utf-8" standalone="no"?>
>>>>>
>>>>> <!DOCTYPE org.jxta:configuration>
>>>>>
>>>>> <jxta>
>>>>>
>>>>>   <peer descriptor="private super peer"/>
>>>>>     <network>
>>>>>     <rendezVous>
>>>>>       <address>//:</address>
>>>>>     </rendezVous>
>>>>>       <relays>
>>>>>       <address>//:</address>
>>>>>     </relays>
>>>>>   </network>
>>>>>     <transport>
>>>>>     <tcp enabled="true">
>>>>>       <address range="100">
>>>>>         <multicast>udp://224.0.1.85:1234</multicast>
>>>>>         tcp://:9700
>>>>>       </address>
>>>>>       <publicAddress>tcp://:9700</publicAddress>
>>>>>       <proxy enabled="false"/>
>>>>>     </tcp>
>>>>>         <http enabled="true">
>>>>>       <address range="100">http://:9700</address>
>>>>>       <publicAddress>http://:9700</publicAddress>
>>>>>       <proxy enabled="false"/>
>>>>>     </http>
>>>>>   </transport>
>>>>>     <service>
>>>>>     <rendezVous enabled="true"/>
>>>>>         <relay enabled="true">
>>>>>       <incoming enabled="true"/>
>>>>>       <outgoing enabled="true"/>
>>>>>     </relay>
>>>>>   </service>
>>>>> </jxta>
>>>>>
>>>>> 1 x Edge peer which should use the superpeer configured above with the
>>>>> following profile
>>>>>
>>>>> <?xml version="1.0" encoding="utf-8" standalone="no"?>
>>>>> <!DOCTYPE org.jxta:configuration>
>>>>>
>>>>> <jxta>
>>>>>
>>>>>   <peer descriptor="private edge"/>
>>>>>     <network>      <rendezVous discovery="false">
>>>>>         <address>tcp://192.168.0.120</address>
>>>>>     </rendezVous>
>>>>>     <relays discovery="false">
>>>>>         <address>tcp://192.168.0.120</address>
>>>>>     </relays>
>>>>>   </network>
>>>>>     <transport>
>>>>>     <tcp>
>>>>>       <address range="100">
>>>>>         <multicast>udp://224.0.1.85:1234</multicast>
>>>>>       </address>
>>>>>       <publicAddress exclusive="false"/>
>>>>>     </tcp>
>>>>>
>>>>>     <http>
>>>>>       <address range="100"/>
>>>>>       <publicAddress exclusive="false"/>
>>>>>       <proxy enabled="false"/>
>>>>>     </http>
>>>>>   </transport>
>>>>>
>>>>>   <service>
>>>>>     <relay>
>>>>>       <outgoing enabled="true"/>
>>>>>     </relay>
>>>>>   </service>
>>>>>
>>>>>   <configuration>
>>>>>     <optimizer class="net.jxta.ext.config.optimizers.EdgeOptimizer"/>
>>>>>   </configuration>
>>>>>   </jxta>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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]
>>>
>>
>> -- 
>> GMX DSL = Maximale Leistung zum minimalen Preis!
>> 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: 
>> http://www.gmx.net/de/go/dsl
>>
>> ---------------------------------------------------------------------
>> 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]
>