LLUP: an overview (reminder)

3 views
Skip to first unread message

Sylvain Hellegouarch

unread,
Nov 5, 2007, 1:26:08 PM11/5/07
to ll...@googlegroups.com
Hi all,

It's been a long time that we haven't updated this list, shame on us. But
it doesn't mean we have given up on LLUP, quite the opposite.

Nonetheless I feel like it's time for to refresh the memory of the good
people subscribed to this list about the ideas behind LLUP.

1. In a nutshell
==========

LLUP, Limited Lifetime Ubiquitous Protocol, is a protocol based on the
exchange of messages called blips within a network of LLUP nodes.

A LLUP network is just a cloud of nodes that are able to accept and
propagate blips. A node that main task is to dispatch new blips is called
a producer. A node that mainly consumes blips is called a consumer,
clients can subscribe to a consumer or be consumers themselves, in the
former case the subscription could be an Atom feed, an XMPP PubSub node,
etc.. Nodes that accept and propagate blips in equal measure are called
routers.

The purpose of a LLUP network is to transit a blip through those routers
until one or two of the following conditions are met:

1. The blip reaches a consumer
2. The blip lifetime is not yet over

The role of each router is to apply a set of filters to fulfill those two
rules. When a consumer gets a blip, it knows it is relevant and not dead.

2. Goal
======

The idea behind LLUP is simple: offer a way to notify the creation,
modification or deletion of a resource located by a URI while giving the
chance for intermediaries to decide in an automated fashion the processing
of that notification.

3. Blip
=====

A blip is a message format containing the following kind of information:

- the type of operation on the resource
- the URI identifying the resource to which the blip relates to using the
atom:link element
- a start, end and expire datetimes defining the life span of the resource
and the blip
- a way to describe a taxonomy, or just to tag a blip using the
atom:category element
- a geo-localisation of the resource using one of the existing geo namespace

As you can see a blip is capable of identifying and describing a resource
as well as placing it in space and time. All this means that a blip is
self-describing and standalone. A blip doesn't relate to other blips. It's
a simple message with meaning on its own.

Note that we have decided to re-use existing and well understood elements
from existing formats such as Atom, Dublin Core or georss rather than
coming up with new ones (although we have some elements belonging to the
llup namespace, but those are limited to handful and straightforward).
However we have decided not to make a blip an atom entry per se as there
would have been too much noise and waste of bandwith in terms of unused
elements. It is possible of course that iterations of LLUP show that we do
need to add more elements.

Note also that the term taxonomy is quite loosely used here. Our goal is
not to create yet a new taxonomy model but rather provide a very simple,
yet straightforwad mechanism to make the semantic of a blip as rich as it
may need to be. M. David Peterson sensibly noticed that the
term+scheme+label triplet of atom:category could well remind the RDF
triplet without having its entire model as a payload.

Finally, a blip is not solely XML. We will define the elements but the
data could well be carried in a JSON or binary format, as long as both the
receiver and the transmitter understand each other.

4. Routers
========

In a LLUP network a router is in charge of filtering a blip based on its
metadata. Each router implements its own logic and this is not defined by
the protocol. The only decision that a router must make is whether or not
a blip can continue its course within the network. If the filtering fails,
then the blip is stopped.

That's an interesting approach against spam to a certain extent because a
router could decide that a blip is actually spam and simply drop the
message, avoiding the consumer to be polluted.

5. Protocol agnostic
==============

LLUP is simple and works because it is protocol agnostic. We have been
asked why we weren't using XMPP and its PubSub extension for instance.
Well an XMPP message is only one potential carrier for blips. We did not
want to be tied to one single protocol for the following reasons:

* That simplifies the adoption of the format and protocol. Not everyone
uses XMPP, BEEP or AMPQ. Besides those may be easy to scale on an intranet
but are not so easily deployed and spread on the Internet itself. The
Jabber commity has to push hard these days to integrate AtomPub and XMPP,
which I think is fantastic, but also shows that XMPP has a very high entry
barrier.

* That allows for routers to demultiplex the propagation of a blip to
different protocols. A router could accept blips using a web service but
dispatch the blip using XMPP or a internal home made network protocol.

* Allows the protocol to be more resilient to the mess that is the
Internet. There is no way around it, the Web cannot be structure as neatly
as some people would love to. So instead of fighting a growing organism,
you should embrace it and go with the flow. LLUP tries to stay out of the
way of how people want to implement the web as much as it can while
offering enough service to justify its use.

In other words, the core of LLUP does not care about whether or not you
use SMTP, XMPP, SMS or HTTP to carry a blip as long as the entity to which
you send it to understand what you are trying to do. It's a gentlemen
agreement ;)

That being said, once the core of the protocol is defined, some extensions
ala XMPP will come up for particular cases.

6. Transcient or persistent?
===================

We have long pushed for the idea that each router must keep every single
blip it receives until it expires. This allows for all kind of added
features. However LLUP does not define how each router decide to store
blips, in fact a router might decide not to store them at all. For now,
this is still an area that needs testing and experience.

7. What for?
=========

Well basically anything where you would have wished to be able to:

1. Break that 1-to-1 relationship between the resource and the consumer of
that resource, providing therefore a place for intermediaries.
2. Push the notification to a cloud knowing that it will either be taken
care of independantly from the resource itself.
3. Do any of these things without RDF ;-)

8. What next?
==========

We have written some LLUP network mockup and they worked just fine, we are
about to write a major LLUP service that will be open source and much more
solid.

Nonetheless there are still some questions open for discussion, for
instance currently there is no "system" or "command" style messages
allowing for nodes to communicate on their capabilities. There is also no
message delivery mechanism defined for now and I'm personally not sure
this would be a good idea anyway.

I hope these few words have clarified again what was LLUP and sparkled
some ideas in your minds about where and how to using it.

http://dev.llup.org

- Sylvain


M. David Peterson

unread,
Nov 5, 2007, 1:48:38 PM11/5/07
to ll...@googlegroups.com
Great overview, Sylvain!  One extension point below,


On 11/5/07, Sylvain Hellegouarch <s...@defuze.org> wrote:

8. What next?
==========

We have written some LLUP network mockup and they worked just fine, we are
about to write a major LLUP service that will be open source and much more
solid.

I think it's safe to suggest that the code we have written is well past the mockup and well into the early stages of an industrial strength solution.  Sylvain and I spent the last six weeks here in Salt Lake City (Sylvain came over from France) cracking out a large portion of the core pieces necessary to finish out the industrial strength publishing and blip distribution system.  We're now busy working with Russ Miles, Jake Joaquin, and Eric Larson (from a full time planning, development, test, release perspective.  Any of you who have the time or interest to get involved, please don't hesitate to speak up :D) binding all of these components together into usable services accessible from a simple, straight forward URI endpoint. We expect this process to take the better part of November and December.

Anyone who would like to keep track of progress can do so via http://nuxleus.googlecode.com/svn/trunk/nuxleus/src > the Nuxleus platform API contained in this directory will eventually be properly documented.  In the mean time please accept the fact that documentation will for all intents and purposes be non-existent until such time as the core API has settled down and we are ready to label the repository v1.0 API complete.  That won't mean it's ready for release, just that the API has been finalized and documentation can be written against it appropriately.

More details on all of the above to follow in the next few weeks.

RicJoh...@gmail.com

unread,
Nov 13, 2007, 10:49:28 AM11/13/07
to llup
M.,

I would love to help!

Do I need SVN access? Should I contact Kurt for doc help? Do you
need unit tests?

Where / When/ what - ANYTHING - just let me know

Ric

On Nov 5, 1:48 pm, "M. David Peterson" <xmlhac...@gmail.com> wrote:
> Great overview, Sylvain! One extension point below,
>
> On 11/5/07, Sylvain Hellegouarch <s...@defuze.org> wrote:
>
>
>
> > 8. What next?
> > ==========
>
> > We have written some LLUP network mockup and they worked just fine, we are
> > about to write a major LLUP service that will be open source and much more
> > solid.
>
> I think it's safe to suggest that the code we have written is well past the
> mockup and well into the early stages of an industrial strength solution.
> Sylvain and I spent the last six weeks here in Salt Lake City (Sylvain came
> over from France) cracking out a large portion of the core pieces necessary
> to finish out the industrial strength publishing and blip distribution
> system. We're now busy working with Russ Miles, Jake Joaquin, and Eric
> Larson (from a full time planning, development, test, release perspective.
> Any of you who have the time or interest to get involved, please don't
> hesitate to speak up :D) binding all of these components together into
> usable services accessible from a simple, straight forward URI endpoint. We
> expect this process to take the better part of November and December.

> Anyone who would like to keep track of progress can do so viahttp://nuxleus.googlecode.com/svn/trunk/nuxleus/src> the Nuxleus platform


> API contained in this directory will eventually be properly documented. In
> the mean time please accept the fact that documentation will for all intents
> and purposes be non-existent until such time as the core API has settled
> down and we are ready to label the repository v1.0 API complete. That won't
> mean it's ready for release, just that the API has been finalized and
> documentation can be written against it appropriately.
>
> More details on all of the above to follow in the next few weeks.
>
> --
> /M:D
>

> M. David Petersonhttp://mdavid.name|http://www.oreillynet.com/pub/au/2354|http://dev.aol.com/blog/3155

Sylvain Hellegouarch

unread,
Nov 13, 2007, 11:07:56 AM11/13/07
to ll...@googlegroups.com
Hey Ric,

You can look there if you want:
http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Messaging/LLUP/
http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Service/LLUP/

The first URL is the basic implementation framework of LLUP.
The second is just a sample on how you could write services thatrun LLUP
components. The documentation is still lacking and you may wonder how
things work, I will look at creating examples when I'll have a bit of
time.

In order to simplify the socket management we use a package called ALAZ
and that you can see at:
http://www.codeproject.com/cs/internet/AsyncSocketServerandClien.asp

The problem is that the documentation on that page has nothing to do with
the current state of the code so you may have some trouble understanding
what's going on. I advise you to look at:
http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Messaging/MessageServer.cs
http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Messaging/MessageService.cs
http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Messaging/MessageClient.cs
http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Messaging/IMessage.cs

Those classes are used with Nuxleus as the base framework for any
client/server package we need to write. They simply expect a service
instance and deal with the socket connections and events.

Hope you can follow the code and feel free to ask :)
- Sylvain

RicJoh...@gmail.com

unread,
Nov 14, 2007, 6:36:54 AM11/14/07
to llup
Sylvain,

Thank you for the reply.

I did find some code previously with some Google hacking. There seems
to be multiple abandoned trees that M. David created in Google Code
and elsewhere. Are the links you send the one true ring, er I mean
code?

Is this code current? Upon review, it looks like just the scaffolding
with some bits filled in, so I assume you have used UML/CASE to design
the architecture first. Do you have the design diagrams?

The best way for me to review the code is to run the code - how would
I do that? Can you grant read access to the latest viable build?

Thanks again,
Ric

On Nov 13, 11:07 am, "Sylvain Hellegouarch" <s...@defuze.org> wrote:
> Hey Ric,
>

> You can look there if you want:http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Messaging...http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Service/L...


>
> The first URL is the basic implementation framework of LLUP.
> The second is just a sample on how you could write services thatrun LLUP
> components. The documentation is still lacking and you may wonder how
> things work, I will look at creating examples when I'll have a bit of
> time.
>
> In order to simplify the socket management we use a package called ALAZ
> and that you can see at:http://www.codeproject.com/cs/internet/AsyncSocketServerandClien.asp
>
> The problem is that the documentation on that page has nothing to do with
> the current state of the code so you may have some trouble understanding

> what's going on. I advise you to look at:http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Messaging...http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Messaging...http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Messaging...http://nuxleus.googlecode.com/svn/trunk/nuxleus/src/Nuxleus.Messaging...

Reply all
Reply to author
Forward
0 new messages