BLIP Basic Lightweight Information Protocol Philosophy, Design Decisions, and Experimental Results

1
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_at_makelist.com
2
BLIP 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.

3
Project Goals

• Open standard for PS messaging
• Prototyping and experimenting
• Aggressive timing goals

4
Project 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

5
Project Goals

• Prototyping and experimenting
• Provide freeware tools
• Provide source code
• Let a thousand flowers bloom

6
Project 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

7
Origins

• Limitations of push

8
Origins

• 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

9
Origins

• Requirements for a Good System

10
Origins

• 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

11
Origins

• Formed blip.org
• Non-profit
• Encourages freeware
• New web site, mailing list

12
Origins

• 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

13
BLIP - 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)

14
BLIP - 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

15
Reliability

• Publish Subscribe
• Reliable Message Queueing
• Open Internet Protocol
• BLIP

16
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

17
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
• Implementation Costs
• Add two-phase commit
• Optional
• All servers must support it
• A topic can turn it off

18
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)

19
Reliability - JMS

• Java Messaging Service (JMS)
• Provides event services
• Limitations
• Sun-directed not open ?
• Java only

Java Client
Java Server
JMS
JMS
20
Reliability - 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
21
Reliability - 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)
22
Reliability - 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
23
Reliability - Databases

• Not required everywhere
• Perceived as slower
• Power not always needed

Custom Filing System
SimpleTopicMgr
Topics
DBTopicMgr
DB
Server
24
Reliability People

• People want notification systems that are
  reliable.
• Almost everything can be mission critical to
  someone.

25
BLIP Software - Current

• Java server
• Java client classes
• Java applets
• Win95 native client
• Perl send/receive scripts
• Simple client OCX
• VB demos

26
BLIP Software - Upcoming

• Palm OS client
• WinCE client
• Native Linux server
• Native NT server
• More applets
• Bridges to MSMQ, MQSeries ?
• Possible JMS wrapper ?

27
The BLIP Protocol
28
The 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

29
The 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

30
The BLIP Protocol - Messages

• SMTP-style headers
• Any MIME type data
• text
• GIF
• HTML
• XML
• etc. ...

31
The BLIP Protocol - Filters?

• Server-side rules
• XML, but how to script?

32
The BLIP Protocol - Filters?

• Server-side rules
• XML, but how to script?
• Currently, repackage data as new topic
• like Event Refinement in Keryx ?

33
The BLIP Protocol

• Multiple access modes
• Improves scaling
• Offers levels of service

34
The BLIP Protocol

• Multiple access modes
• ALIVE

Server
Client
35
The BLIP Protocol

• Multiple access modes
• ALIVE

Server
Client
36
The BLIP Protocol

• Multiple access modes
• ALIVE

Server
Client
37
The BLIP Protocol

• Multiple access modes
• ALIVE

Server
Client
38
The BLIP Protocol

• Multiple access modes
• AWARE

39
The BLIP Protocol

• Multiple access modes
• AWARE

Server
Client
40
The BLIP Protocol

• Multiple access modes
• AWARE

IP
tag
Server
Client
41
The BLIP Protocol

• Multiple access modes
• AWARE

IP
tag
Server
Client
42
The BLIP Protocol

• Multiple access modes
• AWARE

IP
tag
Server
Client
43
The BLIP Protocol

• Multiple access modes
• AWARE

IP
tag
Server
Client
44
The BLIP Protocol

• Multiple access modes
• AWARE

IP
tag
Server
Client
45
The BLIP Protocol

• Multiple access modes
• AWARE

IP
tag
Server
Client
46
The BLIP Protocol

• Multiple access modes
• AWARE

IP
tag
Server
Client
47
The BLIP Protocol

• Multiple access modes
• ALIVE
• Fast - maintains connection
• Expensive - maintains connection
• AWARE
• Slower - create TCP connection
• Scalable - only use needed connections

48
The 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

49
The BLIP Protocol

• Modes allow flexible scaling
• High-priority users get ALIVE mode
• ISPs, paying subscribers
• Low-priority users get AWARE mode

ALIVE
Server
AWARE
50
The BLIP Protocol
200 ALIVE clients per level 3 levels ... 8
million ALIVE clients with 5-10 second
delay(?) can it be coordinated?

• Another example

Proxies/Relayers
Server
Real Clients
51
The BLIP Protocol - Client States
Login
Unauthorized
Ready
Sending
Receiving
52
The BLIP Protocol - Client States
Unauthorized
Ready
Sending
Receiving
S
Transaction
C Acknowledge
53
The 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
54
The 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
55
Issues - Server vs. Point-to-Point

• BLIP is server-based
• Not point-to-point
• Could be used w/ p-to-p tools

56
Issues - 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

57
Issues - Server vs. Point-to-Point

• Example - Spot Demo

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

Delay (ms)
Clients
61
Issues - Server vs. Point-to-Point
62
Issues

• Roaming users and AWARE mode
• multiple active client devices per person?
• Location Server from SIP?
• (Session Initiation Protocol)

63
Issues

• Do Subscribers get messages sent before their
  subscription started?
• Quenching
• Multicast
• Flexibility

64
Issues

• 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
65
End

• Matt Jensen
• mattj_at_blip.org

FOR MORE INFO...

• www.blip.org mailing list
  blip-subscribe_at_makelist.com