[e2e] new network architecture idea -
Jon.Crowcroft at cl.cam.ac.uk
Sun May 21 15:45:57 PDT 2006
pub/sub in the original implementation by tibco et al mapped straight onto multicast
AND had its own transport (PGM) which was a neat architecture
BUT i am not talking about simply pub-/sub - that was for illustration reasons...
at the end of th day, the receiver has some stuff they are interstd in - you buy
newspaer x, or you tune to tv or radio station y/z OR you subscribe to some
belief....all of this is *AND should be* receiver interst based, not sender based
even email (I'm not interested in most the spam i get - this is an indication of a major architectual error
that the cost of an activity for a pasrticipant doesnt match the need -
and the resource expended isnt paid for by the right party)
packet swarming is a simple idea - you need to buy into some complete changes of
ways of building net s (you dont send to an address - you percolate traffic to a repository
cloud which intersted parties may pick packets out of - this works even for 1-1 commnication
(if you send an email to e2e but cc: me, i might see it as i probably "subscribe" to messages
with some field about me - hey, i am sufficiently egomaniacal to want to see stuff like that:)
the technoligy exiwts now to do this at a packet level, not just an application level
In missive <D5775030-CA8B-4329-A7EC-BFC1A56DD3D4 at cisco.com>, Fred Baker typed:
>>On May 20, 2006, at 4:17 PM, Fergie wrote:
>>> pub/sub how, exactly?
>>I think of pub/sub as an application concept: I have content I am
>>willing to share, and someone else tells me that they are interested.
>>In this context, I should think the receiving node would tell the
>>sending node that it was interested if the other guy wanted to talk.
>>So now I wonder how this works. I walk into a meeting room and open
>>my laptop. It joins a wireless network, and voila! the peers and
>>servers I am interested in all tell me that they are publishing
>>something to which I might subscribe?
>>I think this is going to require some work to describe. At the end of
>>the day, it is never the receiver that knows there is content out
>>there to receive; it is always the one who sends it who has that
More information about the end2end-interest