Ido Rosen wrote:
> > >
> > > This application is actually a free public DNS system. The
> > > original infrastructure was written years ago with tightly
> > > integrated hosts and modest growth in mind. The next
> > > generation infrastructure needs to support donated hosts
> > > with variable reliability and limited connectivity.
>
> Could you possibly tell us more about this project? I'm very curious,
> as it sounds like a really good implementation of Jabber. I'm also
> curious though, if there's too much overhead from the Jabber protocol to
> make it feasible in inferior network conditions, like dialup...
I can share more, but I doubt it is of general interest so
let's move this off the jdev list after this reply unless
other people speak up.
The system is called the Public DNS. (You can look at
http://soa.granitecanyon.com/ to learn more.) It hosts DNS
records for free and provides a (very old) web interface
for people to create and update their zones.
The old system, still being used even though the number of
DNS records is huge, requires bulk copies of files on an
infrequent (on the order of hours) basis.
There are a number of obvious problems with that design,
but the biggest problem was recovery when a name server
goes offline for more than a day. We had a donated name
server for a while; donated but still located remotely.
When it was down for any length of time getting it in sync
again was a huge effort. Since this is entirely a volunteer
work, and those of us behind it all have real jobs, that
meant using donated systems made things harder for us, not
easier.
In my copious spare time I've been working on a replacement
infrastructure; creating it from scratch because I did not
see anything that met the following requirements:
1) Asynchronous and reliable delivery of a message even
when the receiver is unavailable when the message is
created.
2) No directly accessible network services. (I was initiating
servers on remote hosts using ssh w/ forced commands to
ensure authorized operation.)
3) Notification of success/failure sent to location other
than sender.
4) Simple, secure, traceable, etc., etc., etc.
I created something that I now know resembled jabber in
surprising ways. True, I called the router a courier, my
address tuple was ([EMAIL PROTECTED]>operation) instead of
([EMAIL PROTECTED]/resource), I used custom HTTP packets instead of
xml, but many things are the same.
The final problem that caused me to find and switch to
Jabber was error handling. I had modified HTTP::Daemon and
LWP::UserAgent to run on a pair of unidirectional pipes
(STDIN/STDOUT) so I could use ssh. However, the HTTP code
kept wanting to close the connection after sending an error
response. I gave up trying to fit a square peg in a round
hole last week.
I'll need to change the architecture a bit, but jabber
should save a lot of time and effort to make it worth it.
The item that will remain, and should be possible once I
really understand jabber, is point #1.
Let me know what aspects pique your interest.
Scott
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
https://jabberstudio.org/mailman/listinfo/jdev
