Transcript Presentation - Karl Thomas Rees

Building a Reliable IP Multicast
Distributed System
Karl Thomas Rees
CS 560
System Needs
• IP telephone-like application, featuring a client
and a dynamic number of operators that
“compete” with each other through a system of
bids to recognize what language the user at the
client end was speaking, and then route the call
accordingly.
• Architecture should be robust enough to be
extendable for use with future NLP projects.
• Naturally, IP Multicast is the underlying protocol
of choice.
Project Steps (minus the NLP)
• Design protocol suitable for transfer of
sound from client to multiple operators.
• Design protocol suitable for transfer of
messages between operators and clients.
• Design protocol stack /API.
• Consider reliability / flow control issues.
Sound Recognition Protocol
• A “super-protocol” that rests on top of IP
Multicast layer:
Sound Stream Protocol
• Class to encapsulate a sound wave.
Foreign Language Recognition
System Protocol
• Messages between operators and clients
FLRS Messages
•
•
•
•
•
•
FLRS_ANNOUNCE
FLRS_BID
FLRS_CLOSE_BIDS
FLRS_ACCEPT
FLRS_REJECT
FLRS_ROUTE
API
• The famous rees.net package. Trust me, it’s
a sweet piece of Java code.
• Built to hide networking aspect. Thus, all
Operators should extend their “Recognizer”
threads from a FLRSPacketHandler that
automatically updates the sound wave /
calls “recognize” method.
Reliability Issues
• FLRS Messages must be guaranteed, otherwise
entire system can crash.
• NLP can be very processor intensive; might not be
able to handle real-time sound as it arrives, so we
need some method of flow control.
• Different operators will be processing the sound
waves with different algorithms and therefore at
different speeds. Don’t want to limit the
performance of the entire system by the flow
needs of the slowest operator.
“Old School” Reliability
Methods
• Sender-initiated Go-Back-N or selective repeat
mechanism for error recovery. Very expensive,
since sender must keep track of state for all
receivers in group.
• Receiver-initiated error recovery (negative acks)
lets receivers keep state, but since we use negative
acks, sender must keep very large buffer and make
assumptions about when its safe to take something
out of the buffer.
• Both strategies suffer from the need to re-send the
data over Multicast, wasting bandwidth network
wide.
Tree-based Multicast Transport
Protocol (TMTP)
1. TMTP uses an expanding ring search to
dynamically organize the dissemination group
members into a hierarchical control tree as
members join and leave a group
2. Receiver driven. Tree structure is exploited to
restrict the scope of retransmissions to the region
where packet loss occurs; thereby insulating the
rest of the network from additional traffic.
3. Problem—needs to be implemented in switches.
Structure-Oriented Resilient
Multicast (STORM)
• Relies on idea that some loss is acceptable.
Also, recognizes that data is time-sensitive.
Eliminates expired data; thus loss is usually
limited to data that would already be
useless.
• Might work for Sound Stream (assuming
we can deal with loss), but not for FLRS.
• Again, implemented in routers.
Waypoints
• Servers called waypoints will be placed
throughout network that participate in the
error recovery protocol, supplying repairs to
receivers. From the application's
perspective, waypoints appear to be
additional application endpoints in the
network. A third-party approach.
Reliable Adaptive Multicast
Protocol (RAMP)
• Can elect to send either reliable or
unreliable.