Title: BLIP Basic Lightweight Information Protocol Philosophy, Design Decisions, and Experimental Results
1BLIP Basic Lightweight Information Protocol
Philosophy, Design Decisions, and Experimental
Results
FOR MORE INFO...
www.blip.org mailing list
blip-subscribe_at_makelist.com
2BLIP Description
- A federated, server-based protocol for near
real-time, robust, scalable, subject-based
publish-and-subscribe messaging. Useful for
user-oriented or system-oriented communication.
3Project Goals
- Open standard for PS messaging
- Prototyping and experimenting
- Aggressive timing goals
4Project Goals
- Open standard for PS messaging
- Platform and Language Neutral
- run anywhere
- handhelds to enterprise server farms
- Simple, text-based wire protocol
- Leverage existing standards
- Robust, can be extended
5Project Goals
- Prototyping and experimenting
- Provide freeware tools
- Provide source code
- Let a thousand flowers bloom
6Project Goals
- Aggressive timing goals
- Early tools available now
- Finalize first-phase protocol in Aug.
- End user tools by September
- Fold lessons learned into next standard
7Origins
8Origins
- Limitations of push
- 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
9Origins
- Requirements for a Good System
10Origins
- Requirements for a Good System
- Open system
- Notification is the essence
- User has fine-grained control over what they
receive, when, and how. - 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 theyve
seen
11Origins
- Formed blip.org
- Non-profit
- Encourages freeware
- New web site, mailing list
12Origins
- Moving beyond Push
- General Notification
- Buddy lists/collaboration tools
- Printers
- System monitoring, security
- Reliability
- Once, only once, in-order, guaranteed delivery
- Support transactions
- Youre already 90 there
- Opens new opportunities
13BLIP - Possible Applications
- Apps for People
- News
- Buddy lists
- Monitoring (email, web pages)
- Security (wheres my kid, my car?)
- Persistent chat
- Auctions
- Stock trading (personal program trading)
14BLIP - Possible Applications
- 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
15Reliability
- Publish Subscribe
- Reliable Message Queueing
- Open Internet Protocol
- BLIP
16Reliability - 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
17Reliability - 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
- Implementation Costs
- Add two-phase commit
- Optional
- All servers must support it
- A topic can turn it off
18Reliability - 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)
19Reliability - JMS
- Java Messaging Service (JMS)
- Provides event services
- Limitations
- Sun-directed not open ?
- Java only
Java Client
Java Server
JMS
JMS
20Reliability - JMS
- Java Messaging Service (JMS)
- Provides event services
- Limitations
- Sun controlled - not open
- Java only
- JMS on top of BLIP/other standard?
JMS is an API for Java, which could use
BLIP/other as underlying protocol.
Java Client
Java Server
JMS
JMS
BLIP
BLIP
21Reliability - JMS
- Java Messaging Service (JMS)
- Provides event services
- Limitations
- Sun controlled - not open
- Java only
- JMS on top of BLIP/other standard?
public interface SimpleBlipAwareness public
void fireBlipMessageReceived( int aTopicID, int
aMessageID, String headline, String
completeMessage) public void
fireBlipError(String e) public void
fireBlipConnectionStateChange( int newState, int
oldState)
22Reliability - Databases
- 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
23Reliability - Databases
- Not required everywhere
- Perceived as slower
- Power not always needed
Custom Filing System
SimpleTopicMgr
Topics
DBTopicMgr
DB
Server
24Reliability People
- People want notification systems that are
reliable. - Almost everything can be mission critical to
someone.
25BLIP Software - Current
- Java server
- Java client classes
- Java applets
- Win95 native client
- Perl send/receive scripts
- Simple client OCX
- VB demos
26BLIP Software - Upcoming
- Palm OS client
- WinCE client
- Native Linux server
- Native NT server
- More applets
- Bridges to MSMQ, MQSeries ?
- Possible JMS wrapper ?
27The BLIP Protocol
28The BLIP Protocol
- What BLIP doesnt do
- Presentation
- topic or client specific
- ACLs
- looking at other standards
- Topic discovery (?)
- ACAP/LDAP
- Advanced security
- Open hook to other systems
29The BLIP Protocol - Subscriptions
- URL-based
- ACLs are out of band
- Different cases
- messages from now on
- messages from 1 on
- start at 10 messages ago
- Default policies
- e.g. - buddy lists
30The BLIP Protocol - Messages
- SMTP-style headers
- Any MIME type data
- text
- GIF
- HTML
- XML
- etc. ...
31The BLIP Protocol - Filters?
- Server-side rules
- XML, but how to script?
32The BLIP Protocol - Filters?
- Server-side rules
- XML, but how to script?
- Currently, repackage data as new topic
- like Event Refinement in Keryx ?
33The BLIP Protocol
- Multiple access modes
- Improves scaling
- Offers levels of service
34The BLIP Protocol
- Multiple access modes
- ALIVE
Server
Client
35The BLIP Protocol
- Multiple access modes
- ALIVE
Server
Client
36The BLIP Protocol
- Multiple access modes
- ALIVE
Server
Client
37The BLIP Protocol
- Multiple access modes
- ALIVE
Server
Client
38The BLIP Protocol
- Multiple access modes
- AWARE
39The BLIP Protocol
- Multiple access modes
- AWARE
Server
Client
40The BLIP Protocol
- Multiple access modes
- AWARE
IP
tag
Server
Client
41The BLIP Protocol
- Multiple access modes
- AWARE
IP
tag
Server
Client
42The BLIP Protocol
- Multiple access modes
- AWARE
IP
tag
Server
Client
43The BLIP Protocol
- Multiple access modes
- AWARE
IP
tag
Server
Client
44The BLIP Protocol
- Multiple access modes
- AWARE
IP
tag
Server
Client
45The BLIP Protocol
- Multiple access modes
- AWARE
IP
tag
Server
Client
46The BLIP Protocol
- Multiple access modes
- AWARE
IP
tag
Server
Client
47The BLIP Protocol
- Multiple access modes
- ALIVE
- Fast - maintains connection
- Expensive - maintains connection
- AWARE
- Slower - create TCP connection
- Scalable - only use needed connections
48The BLIP Protocol
- 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
49The BLIP Protocol
- Modes allow flexible scaling
- High-priority users get ALIVE mode
- ISPs, paying subscribers
- Low-priority users get AWARE mode
ALIVE
Server
AWARE
50The BLIP Protocol
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
51The BLIP Protocol - Client States
Login
Unauthorized
Ready
Sending
Receiving
52The BLIP Protocol - Client States
Unauthorized
Ready
Sending
Receiving
S
Transaction
C Acknowledge
53The BLIP Protocol - A Session
S BLIP 0.46 MODESALIVE S C LOGIN joeuser
mypassword modeALIVE C S 200 - OK. Logged
in. S C !A001 UPDATES ON C S !A001 200 -
OK. S either immediately, or after some time
S UPDATE TXN1 S START ITEM 322 61 S
Headline Inflation is up S Posted 05 Jul 1998
124955 GMT S Content-Length 145 S S The
Federal Reserve. . . S END ITEM (additional
items) S END UPDATE S C !A002 ACK 1 C S
!A002 200 - OK. S
54The BLIP Protocol - Variations
Modes - Server variations
S BLIP 0.46 MODESALIVE S BLIP 0.46
MODESALIVE,AWARE C LOGIN joeuser mypassword
modeALIVE C LOGIN joeuser mypassword
modeALIVE,AWARE C LOGIN joeuser mypassword
modeALIVE C C LOGIN joeuser authXYZ
modeALIVE C Keyde5te4545665r65e4ddhkjdkasiudy75
3sd C
Modes - Client variations
Security - Client variations
55Issues - Server vs. Point-to-Point
- BLIP is server-based
- Not point-to-point
- Could be used w/ p-to-p tools
56Issues - Server vs. Point-to-Point
- With few clients, p-to-p is nice
- reduces server load
- can reduce latency
- could enhance privacy
- With many clients, client gets burdened
- Needs sophisticated programming
- Especially for real-time collaboration
57Issues - Server vs. Point-to-Point
58Issues - Server vs. Point-to-Point
59Issues - Server vs. Point-to-Point
Old user sees this...
New user sees this...
60 Delay (ms)
Clients
61Issues - Server vs. Point-to-Point
62Issues
- Roaming users and AWARE mode
- multiple active client devices per person?
- Location Server from SIP?
- (Session Initiation Protocol)
63Issues
- Do Subscribers get messages sent before their
subscription started? - Quenching
- Multicast
- Flexibility
64Issues
- Dynamic filter control
- How to fine-tune what you receive, on the fly,
without disturbing subscriptions?
C !A0002 UPDATES ON C - /nasdaq/quotes/ C
/nasdaq/quotes/msft C
65End
- Matt Jensen
- mattj_at_blip.org
FOR MORE INFO...
- www.blip.org mailing list
blip-subscribe_at_makelist.com