Скачать презентацию BLIP Basic Lightweight Information Protocol Philosophy Design Decisions Скачать презентацию BLIP Basic Lightweight Information Protocol Philosophy Design Decisions

01e97e900ec859f96da04fc60e018818.ppt

  • Количество слайдов: 65

BLIP Basic Lightweight Information Protocol Philosophy, Design Decisions, and Experimental Results Matt Jensen blip. BLIP Basic Lightweight Information Protocol Philosophy, Design Decisions, and Experimental Results Matt Jensen blip. org FOR MORE INFO. . . www. blip. org mailing list: [email protected] com

BLIP Description l A federated, server-based protocol for near real BLIP Description l A federated, server-based protocol for near real

Project Goals l Open standard for P&S messaging l Prototyping and experimenting l Aggressive Project Goals l Open standard for P&S messaging l Prototyping and experimenting l Aggressive timing goals

Project Goals l Open standard for P&S messaging – Platform and Language Neutral • Project Goals l Open standard for P&S messaging – Platform and Language Neutral • run anywhere • handhelds to enterprise server farms – Simple, text-based wire protocol – Leverage existing standards – Robust, can be extended

Project Goals l Prototyping and experimenting – Provide freeware tools – Provide source code Project Goals l Prototyping and experimenting – Provide freeware tools – Provide source code – Let a thousand flowers bloom

Project Goals l Aggressive timing goals – Early tools available now – Finalize first-phase Project Goals l Aggressive timing goals – Early tools available now – Finalize first-phase protocol in Aug. – End user tools by September – Fold lessons learned into next standard

Origins l Limitations of “push” Origins l Limitations of “push”

Origins of “push” Limitations l – – – – No open standard; big buy-in, Origins of “push” Limitations l – – – – No open standard; big buy-in, ads Little control over info sent Little control over notification techniques Polling is slow, congests corporate network Synchronous - miss messages when offline Limited user-created topics Limited data formats Limited security, reliability

Origins l Requirements for a Good System Origins l Requirements for a Good System

Origins l Requirements for a Good System – – – Open system Notification is Origins l Requirements for a Good System – – – Open system Notification is the essence User has fine-grained control over what they receive, Publishers can send any MIME type data. Persistent messages needed (offline, etc. ) User accounts needed • Publishers want to control access • Subscribers need to keep track of what they’ve seen

Origins l Formed blip. org – Non-profit – Encourages freeware – New web site, Origins l Formed blip. org – Non-profit – Encourages freeware – New web site, mailing list

Moving Originsbeyond Push l – General Notification • Buddy lists/collaboration tools • Printers • Moving Originsbeyond Push l – General Notification • Buddy lists/collaboration tools • Printers • System monitoring, security – Reliability • • Once, only once, in-order, guaranteed delivery Support transactions You’re already 90% there Opens new opportunities

BLIP - Possible Applications l Apps for People – – – – News Buddy BLIP - Possible Applications l Apps for People – – – – News Buddy lists Monitoring (email, web pages) Security (where’s my kid, my car? ) Persistent chat Auctions Stock trading (personal program trading)

BLIP - Possible Applications l Apps for Organizations - Intranet/Extranet news delivery - Custom BLIP - Possible Applications l Apps for Organizations - Intranet/Extranet news delivery - Custom business events - Track inventory levels - Workflow apps (e. g. , DAV) - Transactions - Process orders, coordinate databases, financial transactions - Distributed/parallel processing

Reliability Publish & Subscribe + Reliable Message Queueing + Open Internet Protocol = BLIP Reliability Publish & Subscribe + Reliable Message Queueing + Open Internet Protocol = BLIP

Reliability - Message Queueing – Uses • Tie systems together – distributed processing – Reliability - Message Queueing – Uses • Tie systems together – distributed processing – financial transactions – only send news if you can send bill, too • Personal Assurance – personal apps can be mission-critical

– Uses • Tie systems together Reliability - Message Queueing – distributed processing – – Uses • Tie systems together Reliability - Message Queueing – distributed processing – financial transactions – only send news if you can send bill, too • Personal Assurance – personal apps can be mission-critical – Implementation Costs • Add two-phase commit • Optional – All servers must support it – A topic can turn it off

Reliability - Existing Tools – Publish & Subscribe • Proprietary tools • Many new Reliability - Existing Tools – Publish & Subscribe • Proprietary tools • Many new Java companies • No interoperability or openness – Message Queueing • Very proprietary (MQSeries, MSMQ, etc. ) • Slow efforts at cooperation (BMQ)

Reliability - JMS – Java Messaging Service (JMS) • • Provides event services Limitations Reliability - JMS – Java Messaging Service (JMS) • • Provides event services Limitations Sun-directed; not open ? Java only Java Client Java Server JMS

Reliability - JMS – Java Messaging Service (JMS) • • • Provides event services Reliability - JMS – Java Messaging Service (JMS) • • • Provides event services Limitations JMS is an API for Java, Sun controlled - not open which could use BLIP/other as underlying protocol. Java only JMS on top of BLIP/other standard? JMS BLIP Java Server JMS BLIP Java Client Java Server Other API BLIP Java Client BLIP

Reliability - JMS – Java Messaging Service (JMS) • • • Provides event services Reliability - JMS – Java Messaging Service (JMS) • • • Provides event services Limitations Sun controlled - not open Java only JMS on top of BLIP/other standard? Java Client Java Server Other API public interface Simple. Blip. Awareness { public void fire. Blip. Message. Received( BLIP int a. Topic. ID, int a. Message. ID, String headline, String complete. Message); public void fire. Blip. Error(String e); public void fire. Blip. Connection. State. Change( int new. State, int old. State); } BLIP

Reliability - Databases l Very useful for persistent messages – Offloads queries from event Reliability - Databases l Very useful for persistent messages – Offloads queries from event server – Leverage existing tools • • SQL for queries Proven reliability -- transactions, recoverability High performance (depending on domain) Integration w/ other systems – Middleware community moving this way DB

Reliability - Databases l Not required everywhere – Perceived as slower – Power not Reliability - Databases l Not required everywhere – Perceived as slower – Power not always needed Custom Filing System Simple. Topic. Mgr Topics DBTopic. Mgr DB Server

Reliability & People e want notification systems that are re everything can be mission Reliability & People e want notification systems that are re everything can be mission critical to so

BLIP Software - Current l l l l Java server Java client classes Java BLIP Software - Current l l l l Java server Java client classes Java applets Win 95 native client Perl send/receive scripts Simple client OCX VB demos

BLIP Software - Upcoming l l l l Palm OS client Win. CE client BLIP Software - Upcoming l l l l Palm OS client Win. CE client Native Linux server Native NT server More applets Bridges to MSMQ, MQSeries ? Possible JMS wrapper ?

The BLIP Protocol The BLIP Protocol

The BLIP Protocol l What BLIP doesn’t do – Presentation • topic or client The BLIP Protocol l What BLIP doesn’t do – Presentation • topic or client specific – ACLs • looking at other standards – Topic discovery (? ) • ACAP/LDAP – Advanced security • Open hook to other systems

The BLIP Protocol Subscriptions URL-based l ACLs are out of band l Different cases: The BLIP Protocol Subscriptions URL-based l ACLs are out of band l Different cases: l – messages from now on – messages from #1 on – start at 10 messages ago l Default policies – e. g. - buddy lists

The BLIP Protocol - Messages l SMTP-style headers l Any MIME type data – The BLIP Protocol - Messages l SMTP-style headers l Any MIME type data – – – text GIF HTML XML etc. .

The BLIP Protocol - Filters? l Server-side rules – XML, but how to script? The BLIP Protocol - Filters? l Server-side rules – XML, but how to script?

The BLIP Protocol - Filters? l Server-side rules – XML, but how to script? The BLIP Protocol - Filters? l Server-side rules – XML, but how to script? l Currently, repackage data as new topic – like “Event Refinement” in Keryx ?

The BLIP Protocol l Multiple access modes – Improves scaling – Offers levels of The BLIP Protocol l Multiple access modes – Improves scaling – Offers levels of service

The BLIP Protocol l Multiple access modes – ALIVE Client Server The BLIP Protocol l Multiple access modes – ALIVE Client Server

The BLIP Protocol l Multiple access modes – ALIVE Client Server The BLIP Protocol l Multiple access modes – ALIVE Client Server

The BLIP Protocol l Multiple access modes – ALIVE Client Server The BLIP Protocol l Multiple access modes – ALIVE Client Server

The BLIP Protocol l Multiple access modes – ALIVE Client Server The BLIP Protocol l Multiple access modes – ALIVE Client Server

The BLIP Protocol l Multiple access modes – AWARE The BLIP Protocol l Multiple access modes – AWARE

The BLIP Protocol l Multiple access modes – AWARE Client Server The BLIP Protocol l Multiple access modes – AWARE Client Server

The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server

The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server

The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server

The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server

The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server

The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server

The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server The BLIP Protocol l Multiple access modes – AWARE IP tag Client Server

The BLIP Protocol l Multiple access modes – ALIVE • Fast - maintains connection The BLIP Protocol l Multiple access modes – ALIVE • Fast - maintains connection • Expensive - maintains connection – AWARE • Slower - create TCP connection • Scalable - only use needed connections

The BLIP Protocol l Multiple access modes – ALIVE • Fast - maintains connection The BLIP Protocol l Multiple access modes – ALIVE • Fast - maintains connection • Expensive - maintains connection – AWARE • Slower - create TCP connection • Scalable - only use needed connections – Other modes? • Multicast -- Reliable Multicast very delicate – RFC 2357

The BLIP Protocol l Modes allow flexible scaling – High-priority users get ALIVE mode The BLIP Protocol l Modes allow flexible scaling – High-priority users get ALIVE mode • ISPs, paying subscribers – Low-priority users get AWARE mode ALIVE Server AWARE

The BLIP Protocol l Another example 200 ALIVE clients per level 3 levels. . The BLIP Protocol l Another example 200 ALIVE clients per level 3 levels. . . = 8 million ALIVE clients with 5 -10 second delay(? ) can it be coordinated? Proxies/Relayers Server “Real” Clients

The BLIP Protocol - Client States Login Unauthorized Ready Sending Receiving The BLIP Protocol - Client States Login Unauthorized Ready Sending Receiving

Sending Receiving Transaction Ready Transaction Unauthorized Transaction The BLIP Protocol - Client States S: Sending Receiving Transaction Ready Transaction Unauthorized Transaction The BLIP Protocol - Client States S: C: Acknowledge

The BLIP Protocol - A Session S: S: C: C: S: S: BLIP 0. The BLIP Protocol - A Session S: S: C: C: S: S: BLIP 0. 46 MODES=ALIVE LOGIN joeuser mypassword mode=ALIVE 200 - OK. Logged in. !A 001 UPDATES ON !A 001 200 - OK. either immediately, or after some time… S: S: UPDATE TXN=1 START ITEM #322 61 Headline: Inflation is up Posted 05 Jul 1998 12: 49: 55 GMT Content-Length: 145 The Federal Reserve. . . END ITEM (additional items) S: END UPDATE S: C: !A 002 ACK 1 C: S: !A 002 200 - OK. S:

The BLIP Protocol - Variations Modes - Server variations S: BLIP 0. 46 MODES=ALIVE, The BLIP Protocol - Variations Modes - Server variations S: BLIP 0. 46 MODES=ALIVE, AWARE Modes - Client variations C: LOGIN joeuser mypassword mode=ALIVE, AWARE Security - Client variations C: LOGIN joeuser mypassword mode=ALIVE C: C: LOGIN joeuser auth=XYZ mode=ALIVE C: Key=de 5 te 4545665 r 65 e 4 ddhkjdkasiudy 753 sd C:

Issues - Server vs. Point-to-Point l BLIP is server-based – Not point-to-point – Could Issues - Server vs. Point-to-Point l BLIP is server-based – Not point-to-point – Could be used w/ p-to-p tools

Issues - Server vs. Point-to-Point l With few clients, p-to-p is nice – reduces Issues - Server vs. Point-to-Point l With few clients, p-to-p is nice – reduces server load – can reduce latency – could enhance privacy l With many clients, client gets burdened – Needs sophisticated programming – Especially for real-time collaboration

Issues - Server vs. Point-to-Point l Example - Spot Demo Issues - Server vs. Point-to-Point l Example - Spot Demo

Issues - Server vs. Point-to-Point Issues - Server vs. Point-to-Point

Issues - Server vs. Point-to-Point Old user sees this. . . New user sees Issues - Server vs. Point-to-Point Old user sees this. . . New user sees this. . .

Clients Delay (ms) Clients Delay (ms)

Issues - Server vs. Point-to-Point Issues - Server vs. Point-to-Point

Issues l Roaming users and AWARE mode – multiple ‘active’ client devices person? • Issues l Roaming users and AWARE mode – multiple ‘active’ client devices person? • “Location Server” from SIP? (Session Initiation Protocol)

Issues l Do Subscribers get messages sent before their subscription started? – “Quenching” – Issues l Do Subscribers get messages sent before their subscription started? – “Quenching” – Multicast – Flexibility

Issues l Dynamic filter control – How to fine-tune what you receive, on the Issues l Dynamic filter control – How to fine-tune what you receive, on the fly, without disturbing subscriptions? C: !A 0002 UPDATES ON C: - /nasdaq/quotes/* C: + /nasdaq/quotes/msft C:

End Matt Jensen mattj@blip. org FOR MORE INFO. . . www. blip. org mailing End Matt Jensen [email protected] org FOR MORE INFO. . . www. blip. org mailing list: [email protected] com