OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] RSS beyond the Blog: 1992 or 1999? - was Re:[xml-dev] hur

[ Lists Home | Date Index | Thread Index ]

On Thu, 18 Mar 2004 12:46:52 -0800
"Jeff Rafter" <lists@jeffrafter.com> wrote:
> misnomer. What we really have is HTTP automation scripts masquerading as
> subscription services. If that's all, then why not just insert a
> middle-man that can be repeatedly pinged and let the bank push the data
> to the middle-man? Oh yeah. That's how POP works. That's what we are
> trying to get away from.

It's a solvable problem (not with HTTP, of course (and of course there
will be indignant protests over that outer parenthetical qualification)).

First, note that the connection only needs to happen when the client is
"awake".  That is, the current workaround is client polling.  That wastes
lots of bandwidth in "what's changed?" "nothing" sorts of exchanges.

So, design a simple protocol, such that a *very* simple server can be
built (it needs to be extensively audited for security).  This
"server" is the client (it's listening, so it's a server, but we'll
call it the client the rest of the time here).  On the other side, the
server-server is also relatively simple, which should mean better
security (or at least the possibility of).  When the client obtains an
address, it opens a listening port, and contacts the server with the
client identifier and the current location. The server(to prevent
idiotically easy script kiddie attacks) sends a single challenge to the
advertised port/address, and on receiving a positive response, begins
sending messages.

Now the server only has to send an event whenever state changes on the
server.  The extra overhead goes away.  There is a chance that the client
will drop off the network and the attempted delivery will fail.  And
clients have to deal with renewed dhcp leases that change their address. 
But it still works.  The client *should* notify the server when it leaves
the network; this reduces load on the server.  The server *must* stop
sending messages after [x] messages have gone undelivered.

Actually, it isn't a very hard problem, it's just that the people working
on it all do client/server stuff instead of pub/sub stuff and don't know
the state of the art .... :-)

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
Better to have thirty minutes of wonderful than a lifetime of nothing
special.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS