| Home >> All >> org >> [ jgroups Javadoc ] |
| • | org.jgroups.blocks.* (46) | • | org.jgroups.conf.* (11) | • | org.jgroups.debug.* (7) |
| • | org.jgroups.demos.* (26) | • | org.jgroups.jmx.* (47) | • | org.jgroups.persistence.* (9) |
| • | org.jgroups.protocols.* (115) | • | org.jgroups.stack.* (22) | • | org.jgroups.tests.* (151) |
| • | org.jgroups.util.* (38) |
• org.jgroups: Javadoc index of package org.jgroups.
Package Samples:
• org.jgroups.protocols.pbcast: Provides implementations of transport protocols which are responsible for sending and receiving messages to/from the network.
• org.jgroups.protocols.ring: Provides implementations of transport protocols which are responsible for sending and receiving messages to/from the network.
• org.jgroups.blocks: Provides top-level public JGroups classes such as Channel, Message, etc.
• org.jgroups.protocols: Provides top-level public JGroups classes such as Channel, Message, etc.
• org.jgroups.persistence: Provides top-level public JGroups classes such as Channel, Message, etc.
• org.jgroups.jmx: Provides top-level public JGroups classes such as Channel, Message, etc.
• org.jgroups.conf: Provides top-level public JGroups classes such as Channel, Message, etc.
• org.jgroups.stack: Provides top-level public JGroups classes such as Channel, Message, etc.
• org.jgroups.util: Provides top-level public JGroups classes such as Channel, Message, etc.
• org.jgroups.jmx.protocols
• org.jgroups.jmx.protocols.pbcast
• org.jgroups.demos.wb: Provides demonstrations of JGroups functionality.
• org.jgroups.tests
• org.jgroups.tests.perf.transports
• org.jgroups.tests.perf
• org.jgroups.tests.adaptudp
• org.jgroups.tests.adapttcp
• org.jgroups.tests.adaptjms
• org.jgroups.tests.adapt
• org.jgroups.tests.stack
Classes:
• ENCRYPT: ENCRYPT layer. Encrypt and decrypt the group communication in JGroups The file can be used in two ways: Option 1. Configured with a secretKey in a keystore so it can be used at any layer in JGroups without the need for a coordinator, or if you want protection against passive monitoring but do not want the key exchange overhead and complexity. In this mode all nodes must be distributed with the same keystore file. Option 2. Configured with algorithms and key sizes. The Encrypt Layer in this mode sould be used between the FRAG and PBCast layers in the stack. The coordinator then chooses the secretkey ...
• NAKACK: Negative AcKnowledgement layer (NAKs), paired with positive ACKs. The default is to send a message using NAKs: the sender sends messages with monotonically increasing seqnos, receiver requests retransmissions of missing messages (gaps). When a SWITCH_NAK_ACK event is received, the mode is switched to using NAK_ACKS: the sender still uses monotonically increasing seqnos, but the receiver acknowledges every message. NAK and NAK_ACK seqnos are the same, when switching the mode, the current seqno is reused. Both NAK and NAK_ACK messages use the current view ID in which the message is sent to queue ...
• JChannel: JChannel is a pure Java implementation of Channel. When a JChannel object is instantiated it automatically sets up the protocol stack. Properties Properties are used to configure a channel, and are accepted in several forms; the String form is described here. A property string consists of a number of properties separated by colons. For example: "<prop1>(arg1=val1):<prop2>(arg1=val1;arg2=val2):<prop3>:<propn>" Each property relates directly to a protocol layer, which is implemented as a Java class. When a protocol stack is to be created based on the above property string, ...
• Proxy: Redirects incoming TCP connections to other hosts/ports. All redirections are defined in a file as for example 127.0.0.1:8888=www.ibm.com:80 localhost:80=pop.mail.yahoo.com:110 The first line forwards all requests to port 8888 on to www.ibm.com at port 80 (it also forwards the HTTP response back to the sender. The second line essentially provides a POP-3 service on port 8110, using Yahoo's POP service. This is neat when you're behind a firewall and one of the few services in the outside world that are not blocked is port 80 (HHTP). Note that JDK 1.4 is required for this class. Also, concurrent.jar ...
• CAUSAL: Implements casual ordering layer using vector clocks. Causal protocol layer guarantees that if message m0 multicasted by a process group member p0 causes process group member p1 to multicast message p1 then all other remaining process group members in a current view will receive messages in order m0 followed by m1. First time encountered, causal order seems very similar to FIFO order but there is an important distinction. While FIFO order gurantees that if process group member p0 multicasts m0 followed by m1 the messages will be delivered in order m0,m1 to all other group members, causal order ...
• TOTAL: Implements the total ordering layer using a message sequencer The protocol guarantees that all bcast sent messages will be delivered in the same order to all members. For that it uses a sequencer which assignes monotonically increasing sequence ID to broadcasts. Then all group members deliver the bcasts in ascending sequence ID order. When a bcast message comes down to this layer, it is placed in the pending down queue. A bcast request is sent to the sequencer. When the sequencer receives a bcast request, it creates a bcast reply message and assigns to it a monotonically increasing seqID and sends ...
• UDP_NIO: Multicast transport. Similar to UDP, but binds to multiple (or all) interfaces for sending and receiving multicast and unicast traffic. The list of interfaces can be set via a property (comma-delimited list of IP addresses or "all" for all interfaces). Note that this class only works under JDK 1.4 and higher. For each of the interfaces listed we create a Listener, which listens on the group multicast address and creates a unicast datagram socket. The address of this member is determined at startup time, and is the host name plus a timestamp (LogicalAddress). It does not change during the lifetime ...
• TP: Generic transport - specific implementations should extend this abstract class. Features which are provided to the subclasses include version checking marshalling and unmarshalling message bundling (handling single messages, and message lists) incoming packet handler loopback A subclass has to override sendToAllMembers(byte[], int, int) 55 sendToSingleMember(org.jgroups.Address, byte[], int, int) 55 Protocol.init() > Protocol.init() 55 start() 55 : subclasses must call super.start() after they initialize themselves (e.g., created their sockets). stop() 55 : subclasses must call super.stop() after ...
• GroupRequest: Sends a message to all members of the group and waits for all responses (or timeout). Returns a boolean value (success or failure). Results (if any) can be retrieved when done. The supported transport to send requests is currently either a RequestCorrelator or a generic Transport. One of them has to be given in the constructor. It will then be used to send a request. When a message is received by either one, the receiveResponse() of this class has to be called (this class does not actively receive requests/responses itself). Also, when a view change or suspicion is received, the methods viewChange() ...
• FLUSH: The task of the FLUSH protocol is to flush all pending messages out of the system. This is done before a view change by stopping all senders and then agreeing on what messages should be delivered in the current view (before switching to the new view). A coordinator broadcasts a FLUSH message. The message contains an array of the highest sequence number for each member as seen by the coordinator so far. Each member responds with its highest sequence numbers seen so far (for each member): if its sequence number for a member P is higher than the one sent by the coordinator, it will append the messages ...
• Channel: A channel represents a group communication endpoint (like BSD datagram sockets). A client joins a group by connecting the channel to a group address and leaves it by disconnecting. Messages sent over the channel are received by all group members that are connected to the same group (that is, all members that have the same group address). The FSM for a channel is roughly as follows: a channel is created ( unconnected ). The channel is connected to a group ( connected ). Messages can now be sent and received. The channel is disconnected from the group ( unconnected ). The channel could now be connected ...
• Protocol: The Protocol class provides a set of common services for protocol layers. Each layer has to be a subclass of Protocol and override a number of methods (typically just up() , Down and getName . Layers are stacked in a certain order to form a protocol stack. Events are passed from lower layers to upper ones and vice versa. E.g. a Message received by the UDP layer at the bottom will be passed to its higher layer as an Event. That layer will in turn pass the Event to its layer and so on, until a layer handles the Message and sends a response or discards it, the former resulting in another Event being ...
• TimeScheduler: Fixed-delay & fixed-rate single thread scheduler The scheduler supports varying scheduling intervals by asking the task every time for its next preferred scheduling interval. Scheduling can either be fixed-delay or fixed-rate . The notions are borrowed from java.util.Timer and retain the same meaning. I.e. in fixed-delay scheduling, the task's new schedule is calculated as: new_schedule = time_task_starts + scheduling_interval In fixed-rate scheduling, the next schedule is calculated as: new_schedule = time_task_was_supposed_to_start + scheduling_interval The scheduler internally holds a queue ...
• STABLE: Computes the broadcast messages that are stable; i.e., that have been received by all members. Sends STABLE events up the stack when this is the case. Uses a probabilistic scheme to do so, as described in: GSGC: An Efficient Gossip-Style Garbage Collection Scheme for Scalable Reliable Multicast, K. Guo et al., 1997. The only difference is that instead of using counters for an estimation of messages received from each member, we retrieve this actual information from the NAKACK layer (which must be present for the STABLE protocol to work). Note: the the Event.MSG call path path must be as lightweight ...
• FD_PID: Process-ID based FD protocol. The existence of a process will be tested via the process ID instead of message based pinging. In order to probe a process' existence, the application (or some other protocol layer) has to send down a SET_PID event for the member. The addresses of all members will be associated with their respective PIDs. The PID will be used to probe for the existence of that process. A cache of Addresses and PIDs is maintained in each member, which is adjusted upon reception of view changes. The population of the addr:pid cache is as follows: When a new member joins, it requests ...
• NakReceiverWindow: Keeps track of messages according to their sequence numbers. Allows messages to be added out of order, and with gaps between sequence numbers. Method remove() removes the first message with a sequence number that is 1 higher than next_to_remove (this variable is then incremented), or it returns null if no message is present, or if no message's sequence number is 1 higher. When there is a gap upon adding a message, its seqno will be added to the Retransmitter, which (using a timer) requests retransmissions of missing messages and keeps on trying until the message has been received, or the member ...
• UNICAST: Reliable unicast layer. Uses acknowledgement scheme similar to TCP to provide lossless transmission of unicast messages (for reliable multicast see NAKACK layer). When a message is sent to a peer for the first time, we add the pair to the hashtable (peer address is the key). All messages sent to that peer will be added to hashtable.peer_addr.sent_msgs. When we receive a message from a peer for the first time, another entry will be created and added to the hashtable (unless already existing). Msgs will then be added to hashtable.peer_addr.received_msgs. This layer is used to reliably transmit point-to-point ...
• GossipRouter: Router for TCP based group comunication (using layer TCP instead of UDP). Instead of the TCP layer sending packets point-to-point to each other member, it sends the packet to the router which - depending on the target address - multicasts or unicasts it to the group / or single member. This class is especially interesting for applets which cannot directly make connections (neither UDP nor TCP) to a host different from the one they were loaded from. Therefore, an applet would create a normal channel plus protocol stack, but the bottom layer would have to be the TCP layer which sends all packets ...
• SMACK: Simple Multicast ACK protocol. A positive acknowledgment-based protocol for reliable delivery of multicast messages, which does not need any group membership service. Basically works as follows: Sender S sends multicast message M When member P receives M, it sends back a unicast ack to S When S receives the ack from P, it checks whether P is in its membership list. If not, P will be added. This is necessary to retransmit the next message sent to P. When S sends a multicast message M, all members are added to a retransmission entry (containing all members to which the message was sent), which is ...
• JMS: Implementation of the transport protocol using the Java Message Service (JMS). This implementation depends on the JMS server that will distribute messages published to the specific topic to all topic subscribers. Protocol parameters are: topicName - (required), full JNDI name of the topic to be used for message publishing; cf - (optional), full JNDI name of the topic connection factory that will create topic connection, default value is "ConnectionFactory" ; jndiCtx - (optional), value of the javax.naming.Context.INITIAL_CONTEXT_FACTORY property; you can specify it as the JVM system property -Djava.naming.factory.initial=factory.class.Name ...
• NAKACK: Negative AcKnowledgement layer (NAKs). Messages are assigned a monotonically increasing sequence number (seqno). Receivers deliver messages ordered according to seqno and request retransmission of missing messages. Retransmitted messages are bundled into bigger ones, e.g. when getting an xmit request for messages 1-10, instead of sending 10 unicast messages, we bundle all 10 messages into 1 and send it. However, since this protocol typically sits below FRAG, we cannot count on FRAG to fragement/defragment the (possibly) large message into smaller ones. Therefore we only bundle messages up to max_xmit_size ...
• FD_SOCK: Failure detection protocol based on sockets. Failure detection is ring-based. Each member creates a server socket and announces its address together with the server socket's address in a multicast. A pinger thread will be started when the membership goes above 1 and will be stopped when it drops below 2. The pinger thread connects to its neighbor on the right and waits until the socket is closed. When the socket is closed by the monitored peer in an abnormal fashion (IOException), the neighbor will be suspected. The main feature of this protocol is that no ping messages need to be exchanged between ...
• VotingAdapter: Voting adapter provides a voting functionality for an application. There should be at most one VotingAdapter listening on one org.jgroups.Channel instance. Each adapter can have zero or more registered VotingListener instances that will be called during voting process. Decree is an object that has some semantic meaning within the application. Each voting listener receives a decree and can respond with either true or false. If the decree has no meaning for the voting listener, it is required to throw VoteException . In this case this specific listener will be excluded from the voting on the specified ...
• Ping: Determines the initial set of members given a group name and properties and prints them to stdout. Does not connect to the group, but - using a minimal stack of UPD/PING or TCP/TCPPING - only sends a FIND_INITIAL_MBRS down the stack (PING or TCPPING has to be present for this to work) and waits for FIND_INITIAL_MBRS_OK. When received, the results are printed and then the app terminates. To connect to any group, it is essential that the groupname given (-group) is the same as the one of the group and the properties are the same as the bottom 2 layers of the group properties, e.g. if the group properties ...
• PERF: Measures time taken by each protocol to process a message. PERF has to be the top protocol in a stack. It adds a special header to the message which travels with the message. Upon initialization, PERF creates a ProtocolObserver for each protocol layer in the stack. That observer notes the time taken for a message to travel through the layer it observes, and records the start time, end time and total time in the message itself (in the header created by PERF). When a message is received by PERF, the statistics for the message are appended to a file (or displayed in a GUI (not yet done)). Because ...
| Home | Contact Us | Privacy Policy | Terms of Service |