java.net: Wiki

The Source for Java Technology Collaboration


 <<O>>  Difference Topic AutoConfiguration (4 - 14 Aug 2004 - Main.ramesh_9781)
Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Autoconfigures big goal would be to remove user's from ever having to deal with the

 <<O>>  Difference Topic AutoConfiguration (3 - 02 Apr 2004 - Main.josevoss)
Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Autoconfigures big goal would be to remove user's from ever having to deal with the

 <<O>>  Difference Topic AutoConfiguration (2 - 20 Sep 2003 - Main.bradneuberg)
Line: 1 to 1
 
META TOPICPARENT name="WebHome"
Autoconfigures big goal would be to remove user's from ever having to deal with the
Line: 11 to 11
 
Changed:
<
<
Proposed classes so far:
>
>
Proposed classes so far (I need to modify these to use the existing net.jxta.util.config.* Configurator classes where appropriate):
 Configuration - Represents a peer's JXTA configuration, including the peer's machine and network capabilities. Probably a JavaBean that is bound to XML using one of the XML JavaBean databinding APIs.

 <<O>>  Difference Topic AutoConfiguration (1 - 20 Sep 2003 - Main.bradneuberg)
Line: 1 to 1
Added:
>
>
META TOPICPARENT name="WebHome"
Autoconfigures big goal would be to remove user's from ever having to deal with the Jxta Configurator again. Here's a requirements list:

  • Autodiscover if this peer is behind a NAT device or firewall; if so, it will automatically download a list of public relay servers
  • Probe available bandwidth size, so that programs don't need to have a dialog asking the user what kind of internet connection they have, a common request in many P2P? apps that need to use some peers as super-peers.
  • Probe available CPU processing (probably not possible) and hard-drive space available
  • Turn this peer into a Rendezvous (super-peer) peer or a Relay peer if this peer has the capabilities, and if the peer group it is a member of already doesn't have too many (too many rendezvous or relay peers is just as bad as too little); the last part is probably not possible and might be better as a long term goal


Proposed classes so far:

Configuration - Represents a peer's JXTA configuration, including the peer's machine and network capabilities. Probably a JavaBean that is bound to XML using one of the XML JavaBean databinding APIs.

Autoconfiguration - Probes this peer's machine and network capabilities to automatically set a Configuration object

AutoconfigurationException - Thrown if an exception occurs during autoconfiguration

BootstrapList - Represents a list of public rendezvous and relay servers, and can download these if needed from some address

EndpointSettings - Represents settings for a network endpoint

HttpSettings extends EndpointSettings - Settings to configure this peer to communicate on an HTTP endpoint

TCPSettings extends EndpointSettings - Settings to configure this peer to communicate on a TCP endpoint

ProxySettings - Settings to configure this peer's proxy settings

RendezvousSettings - Settings concerning rendezvous peers, including whether this peer is a rendezvous

RelaySettings - Settings concerning relay peers, including whether this peer is a relay


Entry points into the system based on personnas.

Persona 1: John needs to get a system up and going as quickly as possible. He doesn't even want to know that autoconfiguration is happening and needs no control over it.

His code:

// creates the net peer group.  If no configuration exists, then the JXTA peer
// is configured to use the username "John" and the password "Johnspassword".
// Configuration is done through Autoconfiguration.
PeerGroup netPeerGroup = PeerGroupFactory.newNetPeerGroup("John", "Johnspassword");

Other persona needs to flesh out:

  • Wants to specify a different URL to get a list of public rendezvous and relay servers
  • Wants to have fine-grained control over the autoconfigure probing process so that a UI can be updated as each different thing is probed. For example, while probing the machines CPU abilities the UI would say "Probing CPU capabilities..." and would then change when we moved on to probing whether this peer is behind a NAT device.
  • Wants to have this peer only run on a local intranet
  • Wants to load and save the configuration information from some unusual kind of stream, so that configuration's can be ghosted across many machines or clusters.
  • Wants to find out this machines capabilities, such as hard-drive space, available bandwidth, etc.


Configuration class:
  String : peerName
  String : peerPassword

  boolean : behindNAT
  boolean : behindFirewall
  boolean : needsProxy

  RendezvousSettings: rendezvousSettings
  RelaySettings : relaySettings
  HttpSettings : httpEndpointSettings
  TCPSettings : tcpEndpointSettings
  ProxySettings : proxySettings
  BootstrapList : bootstrapList
  
  int : upstreamBandwidth - the upstream bandwidth of this peer in bytes per second
  int : downstreamBandwidth - the downstream bandwidth of this peer in bytes per second
  int : availableStorage - the available storage space of this peer in megabytes
  

  save() : void - Saves to the filesystem using the default filename and location
  load() : void - Loads from the filesystem using the default filename and location
  save(OutputStream out) : void - Saves configuration into the given filestream
  load(InputStream in) : void - Loads configuration from the given filestream

  autoconfigure() - Autoconfigures everything; delegates to the Autoconfigure class


Autoconfiguration class:
  Configuration : c

  Autoconfiguration(Configuration c)

  probe() : void - calls each probe/configure method; used to probe everything with one call

  probeUpstreamBandwidth() : void
  probeDownstreamBandwidth() : void
  probeAvailableStorage() : void
  probeBehindNATOrFirewall() : void
  configureRelayAndRendezvousSettings() : void
  configureEndpointSettings() : void

  getConfiguration() : Configuration

-- Main.bradneuberg - 20 Sep 2003


Topic AutoConfiguration . { View | Diffs r4 < r3 < r2 < r1 | More }
 XML java.net RSS