[standards-jig] Pub/Sub for JNG?

Dave dave at dave.tj
Wed May 1 03:08:35 UTC 2002


How about allowing multiple "connection types?"  One type can be standard;
another can be SSL; yet another can be gzipped.  In the last "connection
type," every message would be piped through a gzip-compatible deflation
before being pumped out to the network.  The gzip format (like all
LZW algorithms) can tell where the end of the file is supposed to be,
so there's no need to send meta information to alert the receiver to
the point where one message ends and the next begins.  I suspect this
"connection type" would be most useful for s2s connections between
servers exchanging reasonably heavy traffic.

Another interesting "connection type" is aimed squarely at the average
home user who sends <5-word messages per shot.  It's UDP.  The control
connection can still be over TCP (to simplify things, since we do have
TCP available, after all), but all the messages would be sent back and
forth using UDP.  The advantage here is that UDP is substantially faster
for the type of IMming most people tend to do most of the time.  Have most
clients choose the UDP connection as their default for c2s communications,
and you'll see a dramatic improvement in your IM response time.

 - Dave


Iain Shigeoka wrote:
> 
> --- Dave <dave at dave.tj> wrote:
> > Here's something I've been fooling around with for a while.  I know
> > it's not ready for a real spec yet, but I think the flexibility of my
> > proposal is readily apparent, and I hope you folks can help turn this into
> > something that can be used as the foundation for JNG.  Anyway, here 
> 
> Hi Dave,
> 
> I've been thinking along these lines too for a JNG.  Essentially  
> turning jabber transport/server into a generic message queue engine.
> The Jabber protocols become standard ways of using the queues
> to implement IM, primarily as standard naming conventions and 
> use-cases of message queues.
> 
> There are a lot of very interesting things you can do once you have
> a basic framework like that in place.  Especially if security is baked
> into the design from the beginning rather than tacked on afterwards.
> I would think our security system would basically be authentication
> principals, queue access permissions (pub/sub/store), and bind 
> time checks when entities exercise their permissions to access 
> queues.
> 
> Another thing I've been toying with is the thought of how framing can
> improve efficiency for client and server and make the protocol simpler
> and more extensible.  I have some really half-baked ideas on how
> framing combined with queues can be used.  I'm trying to
> think through the issues and benefits.  For example, if you can frame
> any data, and everything is either pub/sub/store to a queue, do we
> have to make everything in the system XML?
> 
> XML definitely has its place but I'm wondering about the majority
> of traffic: short plain text messages.  An effort to optimize certain
> protocols for certain cases may be worthwhile and possible...
> 
> Anyhow, I'm with you Dave.  :)
> 
> -iain
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
> 




More information about the Standards mailing list