NaradaBrokerin
Grid Messaging and
Applications as Web Services
Geoffrey Fox
Community Grids Lab
Indiana University
NaradaBrokering might Support
•
Grid Messaging reliably in spirit of
WS-ReliableMessaging
•
Virtualize inter-service communication
•
Federate different Grids Together
•
Scalable pervasive audio-video conferencing
•
General collaborative Applications and Web services
•
Build next generation clients interacting with messages
not method-based user interrupts
•
Unify peer-to-peer networks and Grids
Minicompute r Firewall Compute r Serve r PDA Mode m Laptop computer Workstatio n Peer s Peer s Audio/Video Conferencing Client Audio/Video Conferencing Client NaradaBrokering Broker Network
NaradaBrokering
QueuesWeb Service A
Web Service B
“GridMPI” v. NaradaBrokering
n In parallel computing, MPI and PVM provided “all the featuresone needed’ for inter-node messaging
n NB aims to play same role for the Grid but the requirements and constraints are very different
• NB is not MPI ported to a Grid/Globus environment
n Typically MPI aiming at microsecond latency but for Grid, time scales are different
• 100 millisecond quite normal network latency
• 30 millisecond typical packet time sensitivity (this is one audio or video
frame) but even here can buffer 10-100 frames on client (conferencing to streaming)
• 1 millisecond is time for a Java server to “think”
n Jitter in latency (transit time through broker) due to routing,
processing (in NB) or packet loss recovery is important property n Grids need and can use software supported message functions and
NaradaBrokering
n
Based on a network of cooperating
broker nodes
• Cluster based architecture allows system to scale in size
n
Originally designed to provide
uniform software
multicast
to support real-time collaboration linked to
publish-subscribe for asynchronous systems.
n
Now has several core functions
• Reliable order-preserving “Optimized” Message transport
(based on performance measurement) in heterogeneous
multi-link fashion with TCP, UDP, SSL, HTTP, and will add GridFTP
• General publish-subscribe including JMS & JXTA and
support for RTP-based audio/video conferencing
• Distributed XML event selection using XPATH metaphor • QoS, Security profiles for sent and received messages
Laudable Features of NaradaBrokering
n
Is
open source
http://www.naradabrokering.org
nH
as
client
“plug-in” as well as standalone brokers
nWill have a
discovery service
to find nearest brokers
nDoes
tunnel
through most firewalls without requiring
ports to be opened
n
Supports
uniform time
across a distributed network
n
Supports
JXTA, JMS
(Java Message Service) and more
powerful native mode
n
Transit time
< 1 millisecond
per broker
n
Will have
setup
and
broker network administration
NaradaBrokering Naturally Supports
n
Filtering
of events to support different client
requirements (e.g,. PDA versus desktop, slow lines,
different A/V codecs)
n
Virtualization
of addressing, routing, interfaces
n
Federation
and
Mediation
of multiple instances of Grid
services as illustrated by
• Composition of Gridlets into full Grids (Gridlets are single
computers in P2P case)
• JXTA with peer-group forming a Gridlet
n
Monitoring
of messages for Service management and
general autonomic functions
n
Fault tolerant
data
transport
Grid Messaging Substrate
Consum
er Service
SOAP+HTT GridFT
RTP ….
Standard client-server style communication.
Substrate mediated
communication removes
transport protocol dependence.
Messaging Substrate Consum
er SOAP+HTTGridFT Service RTP ….
Any Protocol satisfying QoS
Virtualizing Communication
n Communication specified in terms of user goal and Quality of Service – not in choice of port number and protocol
n Protocols have become overloaded e.g. MUST use UDP for A/V latency requirements but CAN’t use UDP as firewall will not support ………
n A given communication can involve multiple transport protocols and multiple destinations – the latter possibly determined
dynamically
Dial-u Filter Satellit
UDP
Firewal HTTP
A
B1
Hand-Hel Protocol Fas
Link
Software Multicast B2
B3
NB Broker Client Filtering
Performance Monitoring
n
Every broker
incorporates a
Monitoring service
that
monitors links
originating from the node.
n
Every link measures and exposes a set of
metrics
• Average delays, jitters, loss rates, throughput.
n
Individual links can
disable
measurements for
individual or the entire set of metrics.
n
Measurement
intervals can
also be varied
n
Monitoring Service,
returns measured
metrics to
Architecture of Message Layer
n Need to optimize not only routing of particular messages butclassic publish/subscribe problem of integrating different
requests with related topics (subscribe to sports/basketball/lakers and sports)
n Related to Akamai, AOL … caching and Server optimization problem
1-> N Grid Clients
Hypercube o
NB Brokers (logical not physical)
NaradaBrokering Communication
n Applications interface to NaradaBrokering through
UserChannels which NB constructs as a set of links between NB Brokers acting as “waystations” which may need to be
dynamically instantiated
n UserChannels have publish/subscribe semantics with XML topics n Links implement a single conventional “data” protocol.
• Interface to add new transport protocols within the
Framework
• Administrative channel negotiates the best available
communication protocol for each link
n Different links can have different underlying transport implementations
• Implementations in the current release include support for
TCP,UDP, Multicast, SSL, RTP and HTTP.
• GridFTP most interesting new protocol
• Supports communication through proxies and firewalls such as
Pentium-3, 1GHz, 256 MB RAM
100 Mbps LAN
JRE 1.3 Linux
hop-3 0 1 2 3 4 5 6 7 8 9 100 1000 Transit Delay (Milliseconds)
Message Payload Size (Bytes)
Mean transit delay for message samples in NaradaBrokering: Different communication hops
hop-2
NaradaBrokering and JMS (Java Message Service)
Low Rate; Small
NaradaBrokering and JXTA Federation
n Based on hybrid proxy that acts as both Rendezvous peer (JXTA routers) and NaradaBrokering end-point.
n No changes to JXTA core or constraints on
interactions
• Change made to Rendezvous
layer
n Peers are not aware that they interact with a
Narada-JXTA proxy or Rendezvous peer.
§ NB provides JXTA guaranteed long distance delivery
End-point Services i
Native NaradaBrokering
n
Allows you to create
Consumers
(subscribers) of events
(an event is a time stamped message where time stamp
can be empty!)
n
Allows you to create
Producers
of events (publishers)
nAllows you to
discover brokers
and
initialize
communications with the broker.
n
Services available at the client side will perform
• Compression of payloads
• Computation of Message digests for Integrity
• Secure encryption of payload based on the specified keys • Fragmentation of large payloads into smaller packets
• Redundancy service which maintains active (alternate)
Event Consumer Capabilities
n Allow you to subscribe to events that conform to a certain template.
• The specified subscription profile could topic-based strings, XPath
queries, <tag=value> pairs or integer topics.
n Event Consumers can also create Consumer constraints to specify various properties regarding the delivery of events. n Consumer constraints are different from subscriptions.
• Subscriptions (or Profiles) are evaluated in a distributed fashion by the
broker network,
• Consumer constraints are QoS related and are managed by the QoS
services running on the end-point.
n Consumer constraints can specify
• Reliable Delivery of events
• Ordered (Publisher, causal and time ordered) delivery of events • Exactly once delivery of events
Event Producer Capabilities
n
Facilitate the
generation
of events in correct format
(next slide)
n
Facilitate the
publishing
of events to brokers
n
Allow the creation of
Publisher constraints
which
facilitate specification of properties that need to be
satisfied by published events
n
Among the constraints that can be specified include
• Method of Securing message payloads
• Computing message digests
• Compressing message payloads
Native NaradaBrokering Event
n The event comprises of• Event headers
• Content Synopsis (for selection as in JMS properties
WITHOUT reading body)
• Content Payload
• Dissemination Traces (generated on the fly as event traverses
broker network)
n This is different from structure of JMS or JXTA events
n This NBEvent structure supports the extra capabilities discussed earlier
n The event headers specify information regarding
• Security and Integrity of encapsulated payload
• Fragmentation of events
• Compression of payloads
• Correlation identifiers (to define ordering between different
streams as is needed in some collaboration applications)
• Priority
• Application Type
Based on Message Level Security Messages organized into topics
Yes No Yes end-to-end Security Yes Yes No
Support forXPath queries/ subscriptions
Yes No
Yes
Communication through proxies and firewalls
Yes No
No
Support forAudio/Video Conferencing& raw RTP clients
JXTA and later Gnutella
Yes No
Support for routing
P2P Interactions Yes Yes Yes Guaranteed Messaging (Robust) No Yes
Medium (MQ is based on the point-to-point model. There is a limit on the
effectiveness of this mode in large configurations). WebSphere MQ (formerly MQSeries) Yes No Network Performance Monitoring Yes No JMS Compliant Very large Very large Maximum number of nodes hosting the messaging
infrastructure
NaradaBrokering
Pastry
Yes No Yes Multiple transport protocolsover multiple hops.
TCP (Blocking and non-blocking), UDP, Multicast, HTTP,
SSL, RTP, (GridFTP)
TCP, UDP TCP, HTTP, Multicast, SSL, SNA etc. Transport Protocols Supported
Fair with some
“production” testing
Fair
Extremely mature,
with very robust
diagnostic information
Maturity of Software
Platforms
supporting Java 1.4 (tunneling C++)
Supported on platforms which support C#
(Microsoft) or Java
(Rice).
35 different OS/
platforms supported. Also supports the Java
Platform.
Platforms or Hosting Environments
No Yes (Squirrel)
No
Support forP2P
Autonomic Services
n In a Web (Grid) Service architecture, the state of any service is defined
by its initial condition and all the messages (including ordering) that it receives
• This how shared event model of collaboration works
n This is a “Finite State Change” model analogous to saving file and
“undo” command in many editors
n NB plus a robust store can “guarantee” to save all these messages for
(all) services
n This allows one to build both "autonomic data transport" and
"autonomic services" since these services can sustain packet losses in transport and can also sustain failures of apps/brokers
• archived messages (previous invocations, published events etc) can
be retransmitted to reconstruct state at the service or to correct a transport error.
n Further anomalies in message traffic (such as a publisher or
subscriber are silent) can be detected by NB and signal problems
n We are building examples of both scenarios using GridFTP as our
data transport example
n We will build a sample autonomic visualization service with detection
Reliable Messaging Standards
• There are 2 competing standards in the Web
Services community
–
WS-Reliability from OASIS
WS-Reliability & WS-RM
•
Specifications provide reliable delivery between two
endpoints.
•
Both the specifications use positive
acknowledgements to ensure reliable delivery
•
Both specifications include support for faults
•
WS-Reliability is a SOAP based protocol
•
WS-ReliableMessaging provides an XML schema for
reliable messaging.
NaradaBrokering & Reliable Delivery specifications
•
We can provide support for both these specifications
– In NaradaBrokering we provide reliable delivery from multiple points to multiple points
•
We have identified issues that will allow federation
between these specifications
– Sequence numbering, fault mappings, numbering rollovers, quality of service guarantees
•
Federation would allow
SequenceTerminated Unknown Sequence InvalidAcknowledgement MessageNumberRollover LastMessageNumberExceeded InvalidMessageHeader Invalid MessageIdentifier InvalidReferenceToMessageId InvalidTimeStamp InvalidExpiryTime InvalidReliableMessage InvalidAckRequested InvalidMessageOrder
Fault Codes supported by protocol
Relies on WS-Security and assorted specifications Relies on WS-Security and assorted specifications
Security
At most once, at least once and exactly once. Order is not necessarily tied to guaranteed delivery.
Exactly once ordered delivery, reliable delivery.
Order is always tied to guaranteed delivery and cannot be separately specified.
Delivery sequences supported
WS-Policy assertions are used to meet delivery assurances. Is initiated by the sender.
Quality of Service
Allows the specification of a RetransmissionInterval for a sequence (effects every message in the sequence). The interval can also be adjusted based on the exponential backoff algorithm. Triggered after receipt of a set of acknowledgements. In the event
an acknowledgement is not received, the message is retransmitted until a specified number of resend attempts have been made. Retransmissions
No explicit reference to UTC. Uses thedateTimeformat. Are expressed as UTC and conforms to a [XML Schema Part2: Data
Types]dateTimeelement. Timestamps
The identifier associated with the sequence of messages and the message number within that sequence.
The identifier associated with the message being acknowledged. Correlation associated with an
Acknowledgement
AckRequested is used to request the receiving entity to acknowledge the message received. This is not REQUIRED.
The AckRequested element is REQUIRED in every message for which reliable delivery needs to be ensured.
Requesting acknowledgements
Acknowledgements can be based on a range of messages, and the timing for issuing this can be advertised in a policy. An endpoint may also choose to send acknowledgements at any time.
Can be sent upon receipt of messages, as a callback or in response to a poll. Needed upon receipt of every message.
Acknowledgements
Message number is REQUIRED for every message that needs to be delivered reliably.
REQUIRED only for guaranteed ordering. Presence of numbering
information and its relation to delivery
No new sequences can be generated.
MessageRolloverfault is issued. Generate a new group identifier and begin new sequence only after
receipt of last message in old sequence. Sequence numbering rollover
Starts at 1 for the first message in a group. Starts at 0 for the first message in a group.
Sequence numbering initialization
URI based [RFC 2396]. No additional requirement. Messages within a sequence are identified based on message numbers.
URI based [RFC 2396], the syntax for the message-ID should be based on what is outlined in RFC2392.
Unique Ids
WS-Policy, WS-Security SOAP, WS-Security
Related Specifications
WSRM provides an XML schema for elements needed to support the reliable messaging framework. The specification provides a SOAP binding for the protocol.
Is a SOAP based protocol, which has an HTTP binding which facilitates acknowledgements and faults to be issued over HTTP responses.
SOAP related issues
NaradaBrokering, WS-Notification & JMS
• NaradaBrokering is JMS compliant
• Topics in NaradaBrokering could be based on XML, String(as in JMS), Plain text, Integers, and (tag=value) tuples.
– Subscriptions could be XPath queries, SQL queries, Regular expressions, Strings and integers
• Almost all the primitives needed in WS-Notification are available in NaradaBrokering
– Exception: Entities never communicate directly with each other, as proposed in WS-Notification.
– We are either allow such direct communication or mimic in NB – no performance overhead!
• We are currently building a prototype implementation of WS-Notification
NaradaBrokering and NTP
• NaradaBrokering includes an implementation of the Network Time Protocol (NTP)
• All entities within the system use NTP to communicate with atomic time servers maintained by organizations like NIST and USNO to compute offsets
– Offset is the computed difference between global time and the local time.
– The offset is computed based on the time returned from multiple atomic time servers.
• The NTP algorithms weighs results from individual time clocks based on the distance of the atomic server from the entity.
• NTP ensures that all entities are within 1-30 milliseconds of each other.
• The timestamps account for clock drifts that take place on machines
NB Time Service
• In figure on left, there is a NTP daemon running on the local machine besides the NB Time Service. NTP daemon running on the machine adjusts the underlying system clock. NB Time Service shows consistent results with NTP daemon. • Figure on right shows results on machine that does not run NTP daemon.
• The following results are obtained over a period of 48 hours.
• In these tests, NB Time Service computes offset every 30 seconds.
Building PSE’s with th
Rule of the Millisecond I
n Typical Web Services are used in situations with interaction delays (network transit)
of 100’s of milliseconds
n But basic message-based interaction architecture only incurs fraction of a
millisecond delay
n Thus use Web Services to build ALL PSE components
• Use messages and NOT method/subroutine call or RPC
n This “rule” OFTEN violated – people use “Java Interfaces” and so cannot distribute
services
Interaction
Nugget
1 Nugget2
Nugget
Building PSE’s with th
Rule of the Millisecond II
n Messaging has several advantages over scripting languages
• Collaboration trivial by sharing messages
• Software Engineering due to greater modularity
• Web Services do/will have wonderful support
n “Loose” Application coupling uses workflow technologies
n Find characteristic interaction time (millisecond programs; microseconds MPI and
particle) and use best supported architecture at this level
• Two levels: Web Service (Grid) and C/C++/C#/Fortran/Java/Python
n Major difficulty in frameworks is NOT building them but rather in supporting them
• IMHO only hope is to always minimize life-cycle support risks
• Science is too small a field to support much!
n Expect to use DIFFERENT technologies at each level even though possible to do
everything with one technology
Streams and Workflow
n
Grids
need to consider
streams
and
Services
• Topics in NB are streams not just individual messages
n
There is
service-oriented workflow
where streams are
typically implicit.
n
For
stream-oriented workflow
, the streams are explicit.
We have built a sophisticated system GlobalMMCS for
audio-video conferencing, which we will discuss next
• Media Industry and sensor based science are different
examples
n
We are building a
stream control engine for
NaradaBrokering
when streams are “just” message
flows on the Grid. Here one would use NB discovery
services – find streams – and monitor
UNIX-style Workflow Example
n
`flow: x &> (y1|z1 &> p,(q|storage1)), (y2|z2|storage2)`
n
Note this approach allows for example all workflow
streams to use RMI, GridFTP, RTP – your or rather
NaradaBrokering’s choice
x
y1 z1 p
y2 z2 storage2
q storage1
Stream–oriented Workflow
n
As in audio-video conferencing and multimedia file
delivery where it’s the media streams that are the
“point”
n
Services generate and transform streams but one thinks
of
streams going through services
rather than
services
generating streams
n
Multi-cast streams where video from one client sent to
all other participants in a collaborative session common
n
One thinks of a stream being published and
participants subscribing to it.
Pub/Sub Queue
Publish
InterGrids Federated Grid using NB
n Build a P2P Network where each component (cell or Gridlet) is itself a Grid
n If cell is a single computer, reduces to using NB to build
communication infrastructure between nodes of P2P network n If cell is a JXTA peer group, then InterGrids includes previous
federation of JXTA Peer Groups
Gridlets NB Brokers
InterGrids Mediation Architecture
n NB acts as a Mediation agent in such a Cellular Grid
n Using federated security model constructs a VPN like Virtual Private Grid (NB could support VPN protocol and combine with Grid Security)
n Mediation includes more than routing (as in current JXTA) as
can map between Interface standards
n Each Gridlet can use different Service standards
n Services register interfaces with mediator giving ways to map
using perhaps OGSA as a common intermediate form
n Allows integration of OGSI WSRF WS-GAF and “pure web service” or Jini or JXTA based Grids where each Grid uses its natural service architecture
n Support interoperable (like Job Submission) and federated
(like registry or metadata catalog) services
Collaboration and Web Services
n
Collaboration
has
• Mechanism to set up members (people, devices) of a
“collaborative sessions”
• Shared generic tools such as text chat, white boards,
audio-video conferencing
• Shared applications such as Web Pages, PowerPoint,
Visualization, maps, (medical) instruments ….
n
b)
and
c)
are “just shared objects” where objects
could be Web Services but rarely are at moment
• We can port objects to Web Services and build a general
approach for making Web services collaborative
n
a)
is a “Service” which is set up in many different
Shared Event Collaboration
n All collaboration is about sharing events defining state changes
• Audio/Video conferencing shares events specifying in compressed form
audio or video
• Shared display shares events corresponding to change in pixels of a frame
buffer
• Instant Messengers share updates to text message streams
• Microsoft events for shared PowerPoint (file replicated between clients) as
in Access Grid
n Finite State Change NOT Finite State Machine architecture n Using Web services allows one to expose updates of all kinds as
messages
• “Event service” for collaboration is similar to Grid notification service
and we effectively define SDE’s (service data elements) in OGSI
n Group (Session) communication service is needed for the delivery of the update events
Collaborative SVG Web Service
n SVG is W3C 2D Vector Graphics standard and is interesting forvisualization and as a simple PowerPoint like application
• Further SVG is built on W3C DOM and one can generalize results
to all W3C DOM-based applications (“all” in future?)
n Apache Batik SVG is Java and open source and so it is practical to modify it to explore
• Real Applications as a Web Service • Collaboration as a Web Service
• MVC model and web services with implications for portlets
n We use NaradaBrokering and XGSP to control collaboration; support PDA Cell-phone and desktop clients; are restructuring Batik as MVC Web Service
• Good progress in all areas see
• http://www.svgarena.org for SVG Games
Applications as Web Services?
n Build “all” classic applications in Web service style with userinterface and “real application” interacting by (WSDL/SOAP) messages and NOT by O/S controlled interrupts
• This is “just” MVC (Model View Control) paradigm done very explicitly • Quite hard because MVC not actually used very systematically
n Perhaps the advantages of this architecture could be enough to shake the Microsoft hegemony in both O/S and “productivity” applications
• Current challenges of Microsoft applications are trying to do as well and
not easy to see how they can do better
n Immediately make a lot easier to support cross O/S applications n Form the “Next Generation Client Consortium”?
• There is quite a lot of open source (but not web service based) software
Web Service Model for Application Development
W3C DOM User Interface W3C DOM Raw (UI) Events
Application as a Web service
W3C DOM Semantic Events Data
User Facin Ports
Resource Facing Ports
Events as Message s Rendering as Messages View Control Model Narad Brokering
Interrupts in traditional monolithic applications becom “real messages” not directly method calls
Natural for collaboration and universal access
Collaborative SVG As A Web Service
Collaborative SVG Chess
Game in Batik Browser
Players
W Displa y W Viewe r WS Displa y WS Viewe r Even (Message Service Master W Displa y WS Viewe r
Web Service Message Interceptor
Collaboration as a W Set up Session with XGSP
Application o Content source WSD L Web Service F I U O F I R O
SV Browse r SV Browse r SV Browse r SV Browse r
Identical Programs receiving identical event
Token determines if browser is moving, waiting for opponent or an observer
SIMD Collaboration
SV
Viewer ViewerSV ViewerSV ViewerSV
SVG Model
(DOM)
NaradaBrokeri ng
Shared Output por
SIMD Collaborativ
Web Service
Non Web Service Implementation
W Displa y W Viewe r WS Displa y WS Viewe r Even (Message Service Master W Displa y WS Viewe r
Collaboration as a W Set up Session with XGSP
We Servic e F I U O F I R O
Shared Input Port (Replicated WS) Collaboration
MIMD Collaboration
SV
Viewer ViewerSV ViewerSV ViewerSV
NaradaBrokering
Shared Input por
MIMD Collaborativ
Web Service
SVG Mode
l
SVG Mode
l
SVG Mode
l
SVG Mode
l
Global-MMCS 2.0 XGSP MCU
n We are building an open source protocol independent WebService “MCU” which will scale to an arbitrary number of users and provide integrated thousands of simultaneous users
collaboration services.
n We will deploy it globally and hope to test with later this year. n The function of A/V media server will be distributed using
NaradaBrokering architecture.
• Media Servers mix and convert A/V streams
n Open XGSP MCU based on the following open source projects
• openh323 is basis of H323 Gateway
• NIST SIP stack is basis of SIP Gateway
• NaradaBrokering is open source messaging from Indiana • Java Media Framework basis of Media Servers
XGSP Web Service MCU Architecture
SIP H323 AccessGrid NativeXGSP
Admire
Gateways convert to uniform XGSP Messaging
High Performance (RTP and XML/SOAP and ..
Media Servers
Filters Session Server
XGSP-based Control
NaradaBrokerin g
All Messaging
Use Multiple Media servers to scale to many codecs and many versions of audio/video mixing
NB Scales a distributed
We Services
A/V Collaboration Systems
n
H323
• H.323 is defined as an umbrella standard specifying the
components to be used within an H.323-based environment.
n
SIP
• The Session Initiation Protocol (SIP) defines how to establish,
maintain and terminate Internet sessions including multimedia conferences
n
Access Grid
• enhanced Mbone A/V tools ( VIC, RAT ) • Internet 2 network ( Multicast support
n
RealStreaming
XGSP Collaboration Framework
n
To integrate heterogeneous systems into one
collaboration system
• A unified, scalable, robust “overlay” network is needed to
support A/V and data group communication over heterogeneous networking environments.
• A common A/V signaling protocol has to be designed to
support interactions between different A/V collaboration endpoints.
• Different A/V endpoints should collaborate in the same
Group Communication in Collaboration
n
Collaboration applications usually need a group
communication service for both multipoint data and
control information delivery
• Centralized conferencing systems usually depend upon a
single conference server
• Distributed conferencing systems use IP multicast
Access Grid uses Internet2 multicast for audio/video transmission.
• Problems: Centralized conferencing systems don’t have good
scalability and IP multicast has not become ubiquitously available
n
We use distributed NaradaBrokering to provide this
A/V Collaboration over publish/subscribe Middleware
n
video streams (VS) VS {v
1, v
2, … v
m}
naudio streams (AS) AS { a
1, a
2, … a
n}
nA/V endpoints: E
1, E
2, … E
lEach endpoint may send a single or multiple video
streams, but only send an audio stream
n
Different types of A/V endpoints have different
collaboration capabilities.
• Multicast endpoints are able to receive multiple video and
audio streams, display all the video streams in their screens, and mix all the audio streams by themselves
• Unicast endpoints like Polycom Via Video can only receive
Publish/subscribe of A/V
n
A stream in VS and AS is regarded as a “topic”
n
Each RTP packet from this stream is regarded as an
“event” for this topic
n
Only the sender of this stream can “publish” A/V
events to this topic
n
Other endpoints need to subscribe to this topic in order
to receive the stream data
n
Create mixed video and audio stream topics for unicast
RTP packets encapsulation
n
RTPLink: RTP Packets map to Narada Brokering
Event
n
Every legacy A/V client needs one corresponding
RTPLink to be set up at a broker within broker
network.
n
Unicast RTPLink:
Integer Topic Numbers for RTP and RTCP
n
Multicast RTPLink:
A reflector between NaradaBrokers and multicast groups,
encapsulating raw RTP packets from a multicast IP address to RTP events, publishing these events to NaradaBrokers, and
Audio Mixer, Video Mixer, Image Grabber
n Audio Mixing
The audio mixer creates a mixed audio stream from all the audio streams in the session
n Video Mixing
Video mixing makes the unicast users watch the pictures of multiple participants in a meeting through one video stream
n Video Thumbnail
visualize the VS set in the session, embedded into the control panel of each endpoint, which
Image grabbers capture video streams and save them as static JPEG files.
n All the media processing components can be distributed among the pool of the media servers connected to NaradaBrokering infrastructures.
H.323, SIP Gateway Servers, A/V Session Server
n
H.323 and SIP gateway transform these protocol
specific messages into XGSP signaling messages so that
H.323 and SIP A/V endpoints could communicate with
the XGSP A/V session server
n
The session server implements session management
logics
• creating/destroying A/V sessions
• allowing endpoints to join/leave session
• Allowing users to make audio/video selection, managing A/V
application components
n
Note Session Server very similar to Context Server in
Streaming Subsystem Servers
Stream Engine Strea m Co nversio n Ha nd ler SMIL File Generator Helix Streaming Server Stream Engine Communication link Pushed streams Process generationn Integration of RealNetwork Streams requires multiple services
Stream Conversion Handler manages and forwards H261 streams
SMIL is W3C standard for synchronizing media streams
0 1 0 2 0 3 0 4 0 5 0 6 0
0 20
0 400 600 800 1000 1200 1400 1600 1800 2000
Delay (Milliseconds)
Packet Number
Average delays per packet for 50
video-clientsNaradaBrokering Avg=2.23 ms, JMF Avg=3.08
ms
NaradaBrokering-RTP
0 1 2 3 4 5 6 7 8
0 20
0 400 600 800 1000 1200 1400 1600 1800 2000
Jit
ter
(Milliseconds)
Packet Number
Average jitter (std. dev) for 50 video clients.
NaradaBrokering Avg=0.95 ms, JMF Avg=1.10
ms
NaradaBrokering-RTP
Polycom, Access Grid
and RealVideo views of
Application Web Service
and Universal Access
n
NaradaBrokering can link
lightweight clients
(V in
MVC) to
Web Services
holding as a Web service the
“guts of an application” (M in MVC)
• This allows customizable user interfaces gotten by mapping
between client profile protocols at NB
• Supports collaboration between diverse clients
Client1
Client2 M
Agent1
Agent2 Profiles NB
P1
P2 P
Map P to P1
Map P to P2