Caching.html 0100644 0000765 0000144 00000002267 07243165673 012204 0 ustar andy users
Caching
Caching
- Maintaining duplicate portions of frequently-needed
state on a client or peer.
- For state that is read in pieces by the client or
repainted frequently, caching speeds up access over
going to the original source for each piece of data.
- Depends on a portion of the state being
serializable for storage on the client or peer.
- Vital for peer systems with large, distributed
state. Frequently requested items need to be cached
throughout the network to reduce bandwidth consumption.
18
ClientServerPatterns.html 0100644 0000765 0000144 00000001731 07243166174 014766 0 ustar andy users
Client/Server Patterns
Client/Server Patterns
- Server should implement a Remote interface,
ensuring that only the small changes to the state
are sent over the network.
- Small amount of state or highly compressible
state could be transferred in whole to a client.
- Client callbacks allow notify-on-change.
7
ClientServerPitfalls.html 0100644 0000765 0000144 00000002114 07243166174 014740 0 ustar andy users
Client/Server Pitfalls
Client/Server Pitfalls
- If the state is large, don't make the root
state object Serializable. Serializable state
could be transferred in its entirety to clients.
- Similarly, when designing a Remote interface,
avoid overly large objects for transfers.
- For state updates from clients, keep updates
as fine-grained as possible, to avoid locking
too much data and blocking other clients.
8
EqualPeers.html 0100644 0000765 0000144 00000001644 07243165614 012707 0 ustar andy users
Equal Peers
Equal Peers
- Each peer maintains a portion of the state,
generally not all.
- Useful if there is a large amount of state, but
instant synchronization to all is not necessary.
- Each peer would usually act as both a server and a
client.
12
EqualPeersPatterns.html 0100644 0000765 0000144 00000001721 07243165614 014424 0 ustar andy users
Equal Peer Patterns
Equal Peer Patterns
- Each peer typically exposes the same
functions, which include ones to provide state
to requesters and accept state changes.
- State-changing functions should be
synchronized, since multiple peers could
potentially provide state changes at the same
time.
13
EqualPeersPitfalls.html 0100644 0000765 0000144 00000002163 07243165614 014403 0 ustar andy users
Equal Peer Pitfalls
Equal Peer Pitfalls
- In a peer network, accessing to a
particular resource can be expensive if the
resource isn't directly reachable.
- In-peer synchronization. If multiple
conversations held simultaneously with
multiple peers, internal state access must be
synchronized.
- Between-peer synchronization. If state must
be consistent between peers, either global
locking or periodic resynchronization must
occur.
14
Granularity.html 0100644 0000765 0000144 00000002004 07243170622 013124 0 ustar andy users
Remote Interface Granularity
Remote Interface Granularity
- RMI invocations have overhead.
- If a large amount of state is to be transferred, prefer a
single large invocation (perhaps compressed) to many
smaller ones
- However, if only portions of the state will be needed by remote side,
consider finer-grained functions to access portions of the state.
20
LocatingPeers.html 0100644 0000765 0000144 00000002536 07243170622 013374 0 ustar andy users
Locating Peers
Locating Peers
- In Client/Server systems, the Server is usually at a
well-known address. Clients are configured with this
address.
- In Peer-based systems, finding peers is somewhat more difficult.
- A central server can hold a list of peers.
At startup, peers ask the server for addresses of
other peers. More than one such server is recommended
to avoid having a single point of failure.
- On the public internet, it is possible to register
with existing services, like IRC or voice chat
systems to share one's IP address with other peers.
- On a small broadcast network, peers can send
broadcast messages to locate one another.
25
NotificationFlexibility.html 0100644 0000765 0000144 00000001727 07243167461 015500 0 ustar andy users
Notification Flexibility
Notification Flexibility
- It may be impossible to predict exactly how your
system is going to be used.
- Example: EMail
- Frequent polling can be used to simulate notification
- A system can be future-proofed by
allowing for an observer pattern internally, even if
it is unused initially.
17
Observer.html 0100644 0000765 0000144 00000002007 07243165673 012427 0 ustar andy users
Observer
Observer
- Peers register with each other; clients register
with a server
- Registration indicates interest in future changes
- When changes occur, the server (or peer with the
change) invokes a handler method on the
registered listeners
- When number of updates is low, or participants want
to know of every change, it's appropriate
16
PatternSelection.html 0100644 0000765 0000144 00000001706 07243170622 014116 0 ustar andy users
Pattern Selection
Pattern Selection
- How often do changes occur in your state?
- Do changes come from one participant or many?
- How much state information do you have?
- How frequently must those changes must be
propagated to listeners, or, do the listeners have to know
every time the state changes?
21
Polling.html 0100644 0000765 0000144 00000002233 07243165673 012245 0 ustar andy users
Polling
Polling
- Peers or clients periodically request updates.
- Is easy to understand.
- Tends to allow a simple protocol.
- Generally lower performance:
- Polls during periods of no state changes
merely waste network bandwidth.
- Increasing the number of peers increases the
amount of requests by the number of polls per
change.
- However, if number of changes is high, and clients
don't need to know of every change, polling can be
appropriate.
15
Questions.html 0100644 0000765 0000144 00000001251 07243170622 012620 0 ustar andy users
Questions
RMI System Design: Patterns and Pitfalls |
O'Reilly Conference On Enterprise Java |
Previous Slide |
|
Questions
- Thank You
- More at frequal.com
- Your Questions
26
Redundancy.html 0100644 0000765 0000144 00000002444 07243170500 012722 0 ustar andy users
Data Redundancy
Data Redundancy
- In systems distributed on unreliable networks,
state must be available from more than one location
to avoid state loss in case of lost hosts or network
partitioning.
- Classic argument between large invulnerable server
and several less reliable but redundant smaller servers.
- Any one portion of the state should be available
from several peers.
- When one peer disappears, another must be nominated
and provided with a copy of the state.
- Peers holding duplicate copies of the state should
be selected to avoid a single common point of
failure -- the backhoe problem.
19
SelectCS.html 0100644 0000765 0000144 00000001727 07243170622 012303 0 ustar andy users
Select Client/Server if:
Select Client/Server if:
- There is a large amount of state.
- Most changes come from one source (place the server there).
- Polling for clients that don't need to know of every change.
- Client callbacks (via Observer pattern) for clients that
need to know of every change soon after it happens.
22
SelectEP.html 0100644 0000765 0000144 00000001641 07243170622 012275 0 ustar andy users
Select Equal Peers if:
Select Equal Peers if:
- Reads and writes come equally from all nodes in the system.
- You want data resiliency.
- Data security isn't a top priority, or all nodes involved
are on a trusted network.
- Peers don't need to know of all state changes.
24
SelectTP.html 0100644 0000765 0000144 00000001527 07243170577 012330 0 ustar andy users
Select Token-Based Peers if:
Select Token-Based Peers if:
- You want to minimize synchronization issues.
- Your state will be manipulated by peers one at a time.
- Peers can block waiting for write access to state.
23
StateExamples1.html 0100644 0000765 0000144 00000001330 07243167257 013476 0 ustar andy users
State Examples
State Examples
- EMail
- Remote network monitoring
- File Sharing
4
StateExamples2.html 0100644 0000765 0000144 00000001352 07243167304 013474 0 ustar andy users
State Examples Continued
State Examples, Continued
- Gaming
- Web Load balancing
- Chat Servers
5
StateTypes.html 0100644 0000765 0000144 00000001422 07243165450 012736 0 ustar andy users
Categories of State
Categories of State
- Volume of information
- Completeness of state
- Urgency of dissemination
- Source of updates
3
TokenPeers.html 0100644 0000765 0000144 00000002534 07243165614 012717 0 ustar andy users
Client/Server
Token-Based Peers
- All peers are capable of maintaining state.
- At any given moment, only one peer holds the token.
- The token permits the owning peer to modify the state.
- That peer is responsible for notifying other peers
of the changes.
- Prevents synchronization problems -- no two peers
will attempt to modify the state at the same time.
- Peer topology
- Ring: Each peer forwards info to the next.
- Star: The token-owning peer sends changes to
all listeners.
- If all peers stay apprised of state changes as
observers, then only token needs to be passed, and
next peer already has full state.
9
TokenPeersPatterns.html 0100644 0000765 0000144 00000001754 07243166146 014444 0 ustar andy users
Token Peer Patterns
Token Peer Patterns
- Small state can be Serializable, and passed
in its entirety.
- Large state should be agreed upon early on,
then modified via a remote interface.
- Modifications to large state can be made by
index or key, or for more complex state, by
Action objects which know how to modify state.
10
TokenPeersPitfalls.html 0100644 0000765 0000144 00000001755 07243165614 014422 0 ustar andy users
Token Peer Pitfalls
Token Peer Pitfalls
- If state is large, passing it whole will be
too slow. Pass updates instead.
- If clients have poor connectivity, client
holding the token could be disconnected and
unable to pass the token.
- A slow peer can block others from accessing
the state for an unacceptable period of time.
11
client-server.html 0100644 0000765 0000144 00000002043 07243165614 013415 0 ustar andy users
Client/Server
Client/Server
- Canoncial state resides on one system, the server
- Clients can view portions of the state, make small
changes
- Usually no single client contains entire state
- Useful for large amounts of state, when individuals
only need to use a portion.
- Server remote interface allows access to the state.
- Examples: EMail, Traditional File Servers
6
intro.html 0100644 0000765 0000144 00000001362 07243165407 011771 0 ustar andy users
RMI System Design: Patterns and Pitfalls
RMI System Design: Patterns and Pitfalls |
O'Reilly Conference On Enterprise Java |
|
Next Slide |
RMI System Design: Patterns and Pitfalls
Andy Oliver
Spirent Communications
andy@frequal.com
1
overview.html 0100644 0000765 0000144 00000001533 07243165430 012500 0 ustar andy users
Overview
Overview
- Categories of State
- Examples of State
- Responsibility Patterns
- Maintaining Coordinated State
- Granularity of Remote Interfaces
- Deciding Which Pattern Is Right For Your System
2