BLIP Basic Lightweight Information Protocol Philosophy, Design Decisions, and Experimental Results Matt Jensen blip. org FOR MORE INFO. . . www. blip. org mailing list: blip-subscribe@makelist. com
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 timing goals
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 – Let a thousand flowers bloom
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 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 – – – 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, mailing list
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 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 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 - 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 – 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 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 Sun-directed; not open ? Java only Java Client Java Server JMS
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 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 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 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 critical to so
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 Native Linux server Native NT server More applets Bridges to MSMQ, MQSeries ? Possible JMS wrapper ?
The BLIP Protocol
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: 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 – – – 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? l Currently, repackage data as new topic – like “Event Refinement” in Keryx ?
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 – AWARE
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 – 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 • 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 • 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. . . = 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
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. 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, 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 be used w/ p-to-p tools
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
Issues - Server vs. Point-to-Point Old user sees this. . . New user sees this. . .
Clients Delay (ms)
Issues - Server vs. Point-to-Point
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” – Multicast – Flexibility
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 list: blip-subscribe@makelist. com
Скачать презентацию BLIP Basic Lightweight Information Protocol Philosophy Design Decisions
01e97e900ec859f96da04fc60e018818.ppt