Docjar: A Java Source and Docuemnt Enginecom.*    java.*    javax.*    org.*    all    new    plug-in

Quick Search    Search Deep

Page 1   2  
net.jxta.access.* (1)net.jxta.build.* (1)net.jxta.codat.* (3)
net.jxta.credential.* (5)net.jxta.discovery.* (3)net.jxta.document.* (19)
net.jxta.endpoint.* (32)net.jxta.exception.* (8)net.jxta.ext.* (58)
net.jxta.id.* (5)net.jxta.impl.* (350)net.jxta.membership.* (3)
net.jxta.meter.* (13)net.jxta.peer.* (4)net.jxta.peergroup.* (6)

net.jxta: Javadoc index of package net.jxta.


Package Samples:

net.jxta.impl.resolver.resolverMeter: A JXTA net.jxta.resolver.ResolverService implementation which implements the standard JXTA Endpoint Resolver Protocol (ERP).  
net.jxta.impl.rendezvous.rpv: A JXTA net.jxta.rendezvous.RendezvousService implementation which implements the standard JXTA Rendezvous Protocol (RVP).  
net.jxta.id.jxta: IDs are used within JXTA to refer to peers, peer groups, pipes and other types of resources.  
net.jxta.impl.membership.pse: The membership service allows a peer to establish an identity within a peer group.  
net.jxta.impl.util.pipe.reliable: A collection of utility classes used by the JXTA implementation.  
net.jxta.access
net.jxta.codat
net.jxta.credential
net.jxta.discovery
net.jxta.document
net.jxta.endpoint
net.jxta.exception
net.jxta.id
net.jxta.membership
net.jxta.meter
net.jxta.peer
net.jxta.peergroup
net.jxta.build
net.jxta.ext.config.optimizers
net.jxta.ext.config.probes

Classes:

Profile: A JXTA configurator that can parse an XML resource and in turn construct the relevant PlatformConfig . All addresses are of the form URI. Addresses that do not specify a scheme will be defaulted accordingly. Further, RendezVous and Relay addresses that do not specify a host wil be replaced with the corresponding boostrap results. If a scheme is specified only bootstrap results with matching schemes will be retained. All other addresses that do not specify a host will, in turn, be replaced with the local host. All fields have backing defaults enabling one to seed a configuration with a partial yet ...
DigestTool: This is a utility class used to create pipe advertisement named and BinaryID for the pipeID to create a private address space that can be hosted in the public discovery system or sent over unencrypted channeds without revealing their intent or purpose. We use a one-way hashing algorythum to create an ID from private information like a user's social security number or a user's email address. We search for the pipe by with this private information securly by creating the matching hash using the same methods. The purpose of this system is to create a way to search for a pipe (or other BinaryID based ...
ModuleClassBinaryID: This interface defines a Module Class Identifier. A ModuleClassID uniquely identifies a particular local behaviour, that is, a specific API for each execution environment for which an implementation exists. A ModuleClassID has two components: A base class identifier, and a role identifier. The role identifier may be zero. By convention the API uses the ModuleClassID with a zero role identifier to designate the base class in contexts where only the base class is significant. Nonetheless, a ModuleClassID with a zero role identifier is a valid ModulesClassID wherever a full ModuleClassID is expected. ...
ModuleClassID: A ModuleClassID uniquely identifies a particular local behaviour, that is, a specific API for each execution environment for which an implementation exists. A ModuleClassID has two components: A base class identifier, and a role identifier. The role identifier may be zero. By convention the API uses the ModuleClassID with a zero role identifier to designate the base class in contexts where only the base class is significant. Nonetheless, a ModuleClassID with a zero role identifier is a valid ModulesClassID wherever a full ModuleClassID is expected. In many cases, only one role in a given class ...
DiscoveryService: The JXTA DiscoveryService provides an asynchronous mechanism for discovering Peer Advertisements, Group Advertisements, and other general JXTA Advertisements (pipe, service, etc.). The scope of discovery can be controlled by specifying name and attribute pair, and a threshold. The threshold is an upper limit the requesting peer specifies for responding peers not to exceed. Each JXTA Peer Group has an instance of a DiscoveryService. The scope of discovery is limited to the group. For example : A peer in the soccer group invokes the soccer group's DiscoveryService to discover pipe advertisements ...
PeerGroup: Peer groups are formed as a collection of peers that have agreed upon a common set of services. Each peer group is assigned a unique peer group ID and a peer group advertisement. The peer group advertisement contains a ModuleSpecID which refers to a module specification for this peer group. The peer group specification mandates each of the group services (membership, discovery, resolver, etc). Implementations of that specification are described by ModuleImplAdvertisements which are identified by the group's ModuleSpecID. Implementations are responsible for providing the services mandated by the ...
MembershipService: The membership service allows a peer to establish an identity within a peer group. Identities are used by services and applications to determine the capabilities available to peers. A peer have any number of identities at one time. Once an identity has been established a credential object is available which allows the peer to prove that it rightfully has that identity. When a peer group is instantiated on a peer the membership service for that peer group establishes a default temporary identity for the peer within the peergroup. This identity, by convention, only allows the peer to establish their ...
JxtaMulticastSocket: The JxtaMulticastSocket class is useful for sending and receiving JXTA multicast packets. A JxtaMulticastSocket is a (UDP) DatagramSocket, with additional capabilities for joining "groups" of other multicast hosts on the internet. A multicast group is specified within the context of PeerGroup and a propagate pipe advertisement. One would join a multicast group by first creating a MulticastSocket with the desired peer group and pipe advertisement : // join a Multicast group and send the group salutations ... String msg = "Hello"; InetAddress group = InetAddress.getByName("228.5.6.7"); MulticastSocket ...
PeerInfoService: The PeerInfoService is a generic API for getting information about the local Peer as well as remote Peers. The most important type of information about a Peer may be gotten through the Monitoring Service that may be accessed via the PeerInfoService. The Monitoring Service provides an open mechanism for reporting any type of Metrics gathered on a Peer by a ServiceMonitor. Attached Service Monitors are identified by their ModuleClassID. A ServiceMonitor may monitor anything (ie it is not restricted to JXTA Services). There are several methods for accessing the capabilities and metrics from ServiceMonitors ...
ResolverService: ResolverService provides a generic mechanism for JXTA Services to send "Queries", and receive "Responses". It removes the burden for registered handlers in deal with : Setting message tags, to ensure uniqueness of tags and ensures that messages are sent to the correct address, and group Authentication, and Verification of credentials drop rogue messages The ResolverService does not proccess the queries, nor does it not compose reponses. Handling of queries, and composition of responses are left up to the registered handlers. Services that wish to handle queries, and generate reponses must implement ...
Credential: Credentials provide the basic mechanisms for securly establishing and communicating identity within JXTA. Credentials have three different roles within JXTA: Authentication credentials are associated with authentication methods and are used to provide information required for authentication. Each AuthenticationCredential implementation is specific to its associated Authenticator . Authentication Credentials are normally created by constructing a document which follows a schema provided by the authentication method. Identity credentials associate an identity with a peer. The peer may request operations ...
EndpointAddress: Describes a destination to which JXTA messages may be sent. This may be: A Pipe A Peergroup (propagate) A Peer A Message Transport for a Peer An Endpoint Address is composed of four components: a protocol (also called a scheme), a protocol address (also called an authority), an optional service name and optional service parameter. The Protocol Describes the method of addressing used by the remainder of the endpoint address. Indicates how the address will be resolved, ie. who will resolve it. Cooresponds to the "scheme" portion of a URI in W3C palance. May not contain the ":" character. The Protocol ...
PipeResolverMsg: This class implements net.jxta.protocol.PipeResolverMessage by providing initialize(Element) 55 and getDocument(MimeMediaType) 55 implementations. It implements the PipeResolver message for the standard Pipe Binding Protocol (PBP) with the following schema: <xs:element name="jxta:PipeResolver" type="jxta:PipeResolver"/> <xs:simpleType name="PipeResolverMsgType"> <xs:restriction base="xs:string"> <!-- QUERY --> <xs:enumeration value="Query"/> <!-- ANSWER --> <xs:enumeration value="Answer"/> </xs:restriction> </xs:simpleType> <xs:complexType name="PipeResolver"> <xs:sequence> ...
PeerGroupFactory: A factory for instantiating the JXTA core peer groups and application peer peer groups. JXTA comes with two peergroup implementations: Platform Implements the world peer group. Every peer starts by instantiating this peer group and then other peer groups are instantiated as needed. The world peer group provides the minimum core services needed to find and instantiate other groups on a peer. Platform has the privilege of assigning a new ID to the peer, if it does not already have one. The World peer group's ID is invariant. StdPeergroup this is currently used to implement all other kinds of peer ...
Messenger: A Messenger is used to send messages to a destination. This interface specifies the allowed observable states for a messenger. (fine grain). This serves to normalize the state machines of the various messenger implementations and allows for more meaningfull diagnostics. Implementations may use substates by adding high order bits, but these should never be reported by the public state observation methods. Most implementations will not use all these states. Each valid state is represented by a integer that is a power of 2. The (coarse grain) constants: USABLE, RESOLVED, TERMINAL, IDLE, SATURATED ...
ModuleSpecAdvertisement: A ModuleSpecAdvertisement describes a module specification. Its main purpose is to provide references to the documentation needed in order to create conforming implementations of that specification. A secondary use is, optionally, to make running instances usable remotely, by publishing any or all of the following: PipeAdvertisement ModuleSpecID of a proxy module ModuleSpecID of an authenticator module Not all modules are usable remotely, it is up to the specification creator to make that choice. However, if the specification dictates it, all implementations can be expected to support it. Note ...
ModuleSpecBinaryID: A ModuleSpecID uniquely identifies a particular network behaviour (wire protocol and choregraphy) that may be embodied by a Jxta Module. There may be any number of implementations of a given SpecID. All such implementations are assumed to be network compatible. The Specification that corresponds to a given ModuleSpecID may be published in a ModuleSpecAdvertisement. This advertisement is uniquely identified by the ModuleSpecID that it describes. The various implementations of a given SpecID may be published in ModuleImplAdvertisements. These advertisements are identified by the ModuleSpecID that ...
ModuleSpecID: A ModuleSpecID uniquely identifies a particular network behaviour (wire protocol and choregraphy) that may be embodied by a Jxta Module. There may be any number of implementations of a given SpecID. All such implementations are assumed to be network compatible. The Specification that corresponds to a given ModuleSpecID may be published in a ModuleSpecAdvertisement. This advertisement is uniquely identified by the ModuleSpecID that it describes. The various implementations of a given SpecID may be published in ModuleImplAdvertisements. These advertisements are identified by the ModuleSpecID that ...
Configurator: A JXTA configurator. Configurator serves primarily as a JXTA property sheet and implements very little attribute association logic beyond that of what is required to perform integrity validation and address expansion. To the latter, All addresses are of the form URI. Addresses that do not specify a scheme will default accordingly. Further, RendezVous and Relay addresses that do not specify a host wil be replaced with the corresponding boostrap results. If a scheme is specified only bootstrap results with matching schemes will be maintained. All other addresses that do not specify a host will, in ...
Codat: Codats are container objects that can hold both data or code and are associated with a JXTA ID. The Codat class is offered as a standard way for applications and services to exchange any kind of contents via a common API and associate a unique JXTA id to these contents. Codats are containers objects that are used to hold any kinds of objects or data. A codat can represent a file, a class file, the saved state of an application, a loadable C library. Codats are handled transparently by the JXTA platform, and are used as placeholders for any types of data. Codats hold Document that represent the ...
LoopbackMessenger: This class implements local delivery of messages ( for example when the InputPipe and the OutputPipe are located on the same peer) The reason this class is useful is that it may not always be possible to connect to oneself without actually going to a relay. If your peer is an http client, it is not able to connect to self through the normal http transport. Since transports cannot be relied on to perform a loopback, some layer above has to figure out that a message is looping back. Since peerid loopback does not explicitly request to go through a real transport, and since peerid addressing is the ...
SimpleACLAccessService: Implements the net.jxta.access.AccessService using a simple ACL scheme. The ACL table is read from the group advertisement. Each perm entry of the Access Service parameters in the group adv is assumed to be a permission in the following format: <operation> ":" ( <identity> )* ( "," <identity> )* A sample ACL table extracted from a PeerGroupAdvertisement: ... <Svc> <MCID>urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE0000001005</MCID> <Parm> <perm><<DEFAULT>>:nobody,permit</perm> <perm>everyone:<<ALL>></perm> <perm>permit:nobody,permit,allow</perm> ...
BTree: BTree represents a Variable Magnitude Simple-Prefix B+Tree File. A BTree is a bit flexible in that it can be used for set or map-based indexing. HashFiler uses the BTree as a set for producing RecordSet entries. The Indexers use BTree as a map for indexing entity and attribute values in Documents. For those who don't know how a Simple-Prefix B+Tree works, the primary distinction is that instead of promoting actual keys to branch pages, when leaves are split, a shortest-possible separator is generated at the pivot. That separator is what is promoted to the parent branch (and continuing up the list). ...
ModuleManager: Module Manager. This class allows to manage modules to be loaded, started and stopped within a PeerGroup. Modules that are loaded using the ModuleManager do not need to be listed within the PeerGroup advertisement, nor do they have to have published their ModuleSpec and ModuleImpl advertisements: the ModuleManager takes care of this task. However, other peers which may want to load the Module will also have to use its own loader (or the ModuleManager itself, of course): the ModuleManager only manages Modules on the local peer. The Module Manager allows, as an option, to use an application provided ...
DiscoveryResponse: DiscoveryResponse. This message is part of the standard JXTA Peer Discovery Protocol (PDP). <xs:element name="DiscoveryResponse" type="jxta:DiscoveryResponse"/> <xs:complexType name="DiscoveryResponse"> <xs:sequence> <xs:element name="Type" type="jxta:DiscoveryQueryType"/> <xs:element name="Count" type="xs:unsignedInt" minOccurs="0"/> <xs:element name="Attr" type="xs:string" minOccurs="0"/> <xs:element name="Value" type="xs:string" minOccurs="0"/> <!-- The following should refer to a peer adv, but is instead a whole doc for historical reasons --> <xs:element name="PeerAdv" ...

Home | Contact Us | Privacy Policy | Terms of Service