[jdev] nonblocking RPCCall() in Net::Jabber, can it work?

[Scott Bolte]

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 (agent at room->operation) instead of
	(id at host/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