![NaradaBrokering and GlobalMMCS 22 July 2004 Grid Summer School Geoffrey Fox Community Grids Lab Indiana University [email_address]](https://image.slidesharecdn.com/ppt1808/85/ppt-1-320.jpg)
![NaradaBrokering can Support ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (17)
Destacado
Similar a ppt
Similar a ppt (20)
Más de Videoguy
Más de Videoguy (20)
ppt
- 1. NaradaBrokering and GlobalMMCS 22 July 2004 Grid Summer School Geoffrey Fox Community Grids Lab Indiana University [email_address]
- 3. NaradaBrokering Web Service B Stream Server-enhanced Messaging NB supports messages and streams NB role for Grid is Similar to MPI role for MPP Queues Minicomputer Firewall Computer Server PDA Modem Laptop computer Workstation Peers Peers Audio/Video Conferencing Client Audio/Video Conferencing Client NaradaBrokering Broker Network
- 8. Current NaradaBrokering Features Prototype implementation of WS-ReliableMessaging Web Service reliability NaradaBrokering enhanced Grid-FTP . Bridge to the Globus TK3 . Grid Application Support Java Message Service ( JMS ) 1.0.2b compliant Support for routing P2P JXTA interactions. Messaging Related Compliance Compression and Decompression of payloads Fragmentation a nd Coalescing of payloads Message Payload options Message-level WS-Security compatible security Security Recovery from failures and disconnects. Replay of events/messages at any time. Recovery and Replay Producer Order and Total Order over a message type Time Ordered delivery using Grid-wide NTP based absolute time Ordered delivery Robust and exactly-once delivery of messages in presence of failures Reliable delivery Subscription can be Strings, Integers, XPath queries, Regular Expressions , SQL and tag=value pairs. Subscription Formats Transport protocols supported include TCP, Parallel TCP streams, UDP, Multicast, SSL, HTTP and HTTPS. Communications through authenticating proxies/firewalls & NATs. Network QoS based Routing Multiple transport support In publish-subscribe Paradigm with different Protocols on each link
- 9. NaradaBrokering Service Integration Proxy Messaging Handler Messaging Notification Internal to Service: SOAP Handlers/Extensions/Plug-ins Java (JAX-RPC) .NET Indigo and special cases: PDA's gSOAP, Axis C++ S1 S2 P2 P1 S1 S2 S1 S2 S? Service P? Proxy NB Transport Standard SOAP Transport Any Transport
- 18. 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 hop-5 hop-7
- 22. NaradaBrokering and JMS (Java Message Service) (commercial JMS) Low Rate; Small Messages
- 29. Yes No Yes end-to-end Security Yes Yes No Support for XPath queries/ subscriptions Yes No Yes Communication through proxies and firewalls Yes No No Support for Audio/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 Functionality I
- 30. Yes No Yes Multiple transport protocols over multiple hops. TCP (Blocking and non-blocking), Parallel TCP, 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 for P2P distributed caching No Yes WebSphere MQ (formerly MQSeries) In Progress No Broker Network Design Interface No No Workflow Support NaradaBrokering Pastry Functionality II
- 44. SM-MV Collaboration Shared Output port Single Model, Multiple View SM-MV Collaborative Web Service XGSP Session Control
- 45. MM-MV Collaboration Shared Input port Multiple Model, Multiple View MM-MV Collaborative Web Service
- 47. XGSP Web Service MCU Architecture Gateways convert to uniform XGSP Messaging High Performance (RTP) and XML/SOAP and .. Use Multiple Media servers to scale to many codecs and many versions of audio/video mixing NB Scales as distributed Web Services NaradaBrokering SIP H323 Access Grid Native XGSP Admire Media Servers Filters Session Server XGSP-based Control NaradaBrokering All Messaging
- 50. 0 10 20 30 40 50 60 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Delay (Milliseconds) Packet Number Average delays per packet for 50 video-clients NaradaBrokering Avg=2.23 ms, JMF Avg=3.08 ms NaradaBrokering-RTP JMF-RTP
- 51. 0 1 2 3 4 5 6 7 8 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Jitter (Milliseconds) Packet Number Average jitter (std. dev) for 50 video clients. NaradaBrokering Avg=0.95 ms, JMF Avg=1.10 ms NaradaBrokering-RTP JMF-RTP
- 52. Polycom, Access Grid and RealVideo views of video-mixed streams using GlobalMMCS
- 53. Integration of PDA, Cell phone and Desktop Grid Access NB Support for optimized PDA Communication
Notas del editor
- Every broker in NaradaBrokering incorporates a monitoring service (as shown in Figure 12) that monitors the state of the links originating from the broker node. Metrics computed and reported over individual links, originating from a broker node, include bandwidth , jitter , transit delays , loss rates and system throughputs . Factors are measured in a non-intrusive way so as to ensure that the measurements do not further degrade the metrics being measured in the first place. Factors such as bandwidth measurements, which can pollute other metrics being measured, are measured at lesser frequencies. Furthermore, once a link is deemed to be at the extreme ends of the performance spectrum (either very good or very bad) the measurement of certain factors are turned off while others are measured at a far lower frequency . The monitoring service then reports this data to a performance aggregator node, which aggregates information from monitoring services running at other nodes.
- The integration is based on the proxy model, which essentially acts as the bridge between the NaradaBrokering system and JXTA. The Narada-JXTA proxy, operating inside the JXTA rendezvous layer, serves in a dual role as both a rendezvous peer and as a NaradaBrokering client providing a bridge between NaradaBrokering and JXTA. NaradaBrokering could be viewed as a service by JXTA. We make no changes to the JXTA core and the associated protocols. We make additions to the rendezvous layer for integration purposes. Second, this integration should entail neither any changes to the peers nor a restriction of the interactions that these peers could have had prior to the integration. Peers do not know that the broker network is routing some of their interactions. Furthermore, these Narada-JXTA proxies, since they are configured as clients within the NaradaBrokering system, inherit all the guarantees that are provided to NaradaBrokering clients.
- The figure above depicts the sequence of operations involved in securing messaging within NB. When an entity requests permission to publish, the KMC responds back with a topic key if the entity is authorized to publish to the topic. The entity then proceeds to encrypt the message with the topic key, compute a message digest and sign the message digest with its personal private-key. Individual Brokers upon receipt of the secure message can verify the entity signatures and permissions. If it is not authorized to publish or if the message integrity is compromised (revealed by the message digest) the message is discarded. When an entity requests permission to subscribe to a topic, the KMC returns it the topic keys if the entity is authorized to subscribe. Since the subscription needs to be propagated within the system, the entity propagates its subscription request by signing the request with its personal public-key. Upon receipt of a secure message, the subscriber verifies the signature and integrity of the message. It then proceeds to decrypt the secure message with the KMC supplied secret topic-key.
- Standarad deviation between inter packet arrival times