All Packages from net.jxta.impl.access.* to net.jxta.impl.meter.*

Home >> All >> net >> jxta >> [ impl Javadoc ]

Page 1 2

•	net.jxta.impl.access.* (5)	•	net.jxta.impl.cm.* (8)	•	net.jxta.impl.config.* (1)
•	net.jxta.impl.discovery.* (2)	•	net.jxta.impl.document.* (11)	•	net.jxta.impl.endpoint.* (75)
•	net.jxta.impl.id.* (36)	•	net.jxta.impl.loader.* (1)	•	net.jxta.impl.membership.* (18)
•	net.jxta.impl.meter.* (7)

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

Package Samples:

• net.jxta.impl.membership.pse: The membership service allows a peer to establish an identity within a peer group.
• net.jxta.impl.access.always
• net.jxta.impl.access.simpleACL
• net.jxta.impl.access
• net.jxta.impl.cm
• net.jxta.impl.config
• net.jxta.impl.discovery
• net.jxta.impl.document
• net.jxta.impl.endpoint.cbjx
• net.jxta.impl.endpoint.endpointMeter
• net.jxta.impl.endpoint.msgframing
• net.jxta.impl.endpoint.relay
• net.jxta.impl.endpoint.router
• net.jxta.impl.endpoint.servlethttp
• net.jxta.impl.endpoint.tcp
• net.jxta.impl.endpoint.tls
• net.jxta.impl.endpoint.transportMeter
• net.jxta.impl.endpoint
• net.jxta.impl.id.CBID
• net.jxta.impl.id.UUID

Classes:

• 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. ...
• 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">  <xs:enumeration value="Query"/>  <xs:enumeration value="Answer"/> </xs:restriction> </xs:simpleType> <xs:complexType name="PipeResolver"> <xs:sequence> ...
• 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 ...
• 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>&lt;&lt;DEFAULT>>:nobody,permit</perm> <perm>everyone:&lt;&lt;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"/>  <xs:element name="PeerAdv" ...
• Srdi: Srdi is a service which provides Srdi functionalities such as : pushing of Srdi messages to a another peer/propagate replication of an Srdi Message to other peers in a given peerview given an expression Srdi provides a independently calculated starting point Forwarding a ResolverQuery, and taking care of hopCount, random selection registers with the RendezvousService to determine when to share Srdi Entries and whether to push deltas, or full a index provides a SrdiInterface giving to provide a generic srdi message definition If Srdi is started as a thread it performs periodic srdi pushes of indices ...
• UUID: A UUID is a 128-bit universally unique identifier. The most significant long can be decomposed into the following unsigned fields: 0xFFFFFFFF00000000 time_low 0x00000000FFFF0000 time_mid 0x000000000000F000 version 0x0000000000000FFF time_hi The least significant long can be decomposed into the following unsigned fields: 0xC000000000000000 variant 0x3FFF000000000000 clock_seq 0x0000FFFFFFFFFFFF node The variant field must be 0x2. The version field must be either 0x1 or 0x4. If the version field is 0x4, then the most significant bit of the node field must be set to 1, and the remaining fields are ...
• PSECredential: This class provides the sub-class of Credential which is associated with the PSE membership service. There are two varients of the credential: local - Generated as a result of local login. This type of credential can be used for signing and can be serialized for inclusion in protocols. remote - Generated as a result of deserialization from protocols. The credential is verified to ensure that the contents are valid at the time it is created. The schema for this credential format: <xs:element name="PSECred" type="jxta:PSECred" /> <xs:complexType name="PSECred"> <xs:sequence> <xs:element ...
• DiscoveryQuery: Implements the Discovery Query Message according to the schema defined by the standard JXTA Peer Discovery Protocol (PDP). <xs:element name="DiscoveryQuery" type="jxta:DiscoveryQuery"/> <xsd:simpleType name="DiscoveryQueryType"> <xsd:restriction base="xsd:string">  <xsd:enumeration value="0"/>  <xsd:enumeration value="1"/>  <xsd:enumeration value="2"/> </xsd:restriction> </xsd:simpleType> <xs:complexType name="DiscoveryQuery"> <xs:sequence> <xs:element name="Type" type="jxta:DiscoveryQueryType"/> <xs:element name="Threshold" ...
• ResolverQuery: Implements the Resolver Query Message according to the schema defined by the core JXTA Peer Resolver Protocol (PRP). <xs:element name="ResolverQuery" type="jxta:ResolverQuery"/> <xs:complexType name="ResolverQuery"> <xs:all> <xs:element ref="jxta:Cred" minOccurs="0"/> <xs:element name="SrcPeerID" type="jxta:JXTAID"/> <xs:element name="SrcPeerRoute" type="jxta:JXTA RouteAdv"/>  <xs:element name="HandlerName" type="xs:string"/> <xs:element name="QueryID" type="xs:string"/> <xs:element name="HC" type="xs:unsignedInt"/> ...
• Destinations: This class is a repository of wisdom regarding destinations. It also provides a messenger if there is one. Currently, the wisdom is very limited and is only about direct destinations (for which a messenger once existed). The wisdom that can be obtained is: is there a messenger at hand (incoming or otherwise). is it likely that one can be made from this end, should the one we have break. (the last attempt succeeded, not only incoming, and that was not long ago). is either of the above true, (are we confident we can get a messenger as of right now one way or the other). are we supposed to send a ...
• DiscoveryServiceImpl: This Discovery Service implementation provides a mechanism to discover peers within the horizon of the resolver service. The horizon is normally restricted to the group's boundaries but this is not an absolute requirement. Use of the Resolver service is not an absolute requirement either for a discovery service, but this is what this is part of the platform and default net peer group protocol set, which this code implements. This implementation uses the standard JXTA Peer Discovery Protocol (PDP). The DiscoveryService service also provides a way to obtain information from a specified peer and request ...
• BlockingMessenger: This class is a near-drop-in replacement for the previous BlockingMessenger class. To subclassers (that is, currently, transports) the only difference is that some overloaded methods have a different name (class hierarchy reasons made it impossible to preserve the names without forcing an API change for applications). The other difference which is not API visible, is that it implements the standard MessengerState behaviour and semantics required by the changes in the endpoint framework. This the only base messenger class meant to be extended by outside code that is in the impl tree. The reason ...
• PeerInfoResponseMsg: This class implements net.jxta.protocol.PeerInfoResponseMessage . This message is part of the Peer PeerInfoService protocol <xs:element name=" PeerInfoResponse " type="jxta:PeerInfoResponse"/> <xs:complexType name="PeerInfoResponse"> <xs:element name="sourcePid" type="xs:anyURI"/> <xs:element name="targetPid" type="xs:anyURI"/> <xs:element name="uptime" type="xs:unsignedLong" minOccurs="0"/> <xs:element name="timestamp" type="xs:unsignedLong" minOccurs="0"/> <xs:element name="response" type="xs:anyType" minOccurs="0"/> </xs:complexType>
• TcpMessenger: Implements a messenger which sends messages via raw TCP sockets. FIXME jice@jxta.org 20021007: Although in theory not too clean, we could merge connection and messenger. there is a one-to-one mapping between them except that for incoming connections we sometimes throw the messenger away. Merging them would add only a message element and an endpoint address to the connection object and would simplify close() isclosed() and GC's life quite a bit. (Look Ma, no synch ! All synchronized() have been removed. With the help of a volatile reference to the TcpConnection, this is no longer necessary this ...
• PeerAdv: Implementation of net.jxta.protocol.PeerAdvertisement matching the standard JXTA Protocol Specification. It implements Peer Advertisement using the following schema: <xs:complexType name="PA"> <xs:sequence> <xs:element name="PID" type="JXTAID"/> <xs:element name="GID" type="JXTAID"/> <xs:element name="Name" type="xs:string" minOccurs="0"/> <xs:element name="Desc" type="xs:anyType" minOccurs="0"/> <xs:element name="Svc" type="jxta:serviceParams" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence> </xs:complexType>
• ModuleImplAdv: This class implements the Module Implemenation Advertisement according to the schema defined by the JXTA Core Specification. <xs:complexType name="MIA"> <xs:sequence> <xs:element name="MSID" type="jxta:JXTAID"/> <xs:element name="Comp" type="xs:anyType"/> <xs:element name="Code" type="xs:anyType"/> <xs:element name="PURI" type="xs:anyURI" minOccurs="0"/> <xs:element name="Prov" type="xs:string" minOccurs="0"/> <xs:element name="Desc" type="xs:anyType" minOccurs="0"/> <xs:element name="Parm" type="xs:anyType" minOccurs="0"/> </xs:sequence> </xs:complexType>
• QuotaIncomingMessageListener: A wrapper around an EndpointListener which imposes fair sharing quotas. NOTE : 20020526 jice There would be great value in making such an object the explicit interface between the endpoint and its clients, rather than a bland listener interface The client would have the ability to specify the threads limit, possibly setting it zero, and then could have access to the buffer. To implement that with a simple listener would mean that the endpoint has to TRUST the client that the listener does no-more than queuing and signaling or else, force a full and possibly redundant hand-shake in all cases, as ...
• PeerInfoQueryMsg: This class implements net.jxta.protocol.PeerInfoQueryMessage . This message is part of the Peer PeerInfoService protocol <xs:element name=" PeerInfoQueryMessage " type="jxta:PeerInfoQueryMessage"/> <xs:complexType name="PeerInfoQueryMessage"> <xs:element name="sourcePid" type="xs:anyURI"/> <xs:element name="targetPid" type="xs:anyURI"/>  <xs:element name="request" type="xs:anyType" minOccurs="0"/> </xs:complexType>
• Dlist: A cheap doubly linked list. It is far less general than java's LinkedList but permits much better removal performance from the middle of the list because a contained element and the corresponding chaining object are one and the same. The major inconvenient of Dlink is that it is a class, not an interface. Making it an interface does not make sense since one would have to re-implement it entirely. A DList is just a stand-alone Dlink with just a couple of additional convenience methods. Note this class does not keep an element count. The way element removal works makes it impossible. Do it from the ...
• PeerView: This class models a Rendezvous Peer View (RPV): ordered collection of all other Rendezvous Peers visible to this Peer. Presently this class implements a random "diffusion" algorithm where each Peer periodically selects a randomly selected peer advertisement from its view and sends it over to a randomly selected peer from its view. Over time, this causes every peer to learn about every other peer, resulting in a "consistent" peer view. This diffusion process is bootstrapped by every peer sending their own peer advertisements to some well-known, stable, "seed" peers on startup.

Home | Contact Us | Privacy Policy | Terms of Service