alexis@panix.uucp (Alexis Rosen) (06/28/91)
We feed from a large site that we're generally very happy with. We have no
need for another feed on a regular basis- they supply us with everything.
But 2 or 3 times a year they'll go down for a few days. At such points, the
newsflow stops and when it restarts, it takes a while to catch up. Then there's
a 60MB hump in the newsflow that brings us close to the edge (or maybe even
over) on our news partition. Yuck.
What we'd like to do is set up a backup feed. Can anyone think of any serious
problems with the following plan?
1) Set up software so that news can flow in both directions, then turn off
batching. Have the backup admin do the same.
2) Watch for newsfeed failure.
3) When it fails, send a message asking the backup feed's admin to turn on
batching.
4) When first newsfeed starts up again have remote turn off batching.
There are a few details. You could turn off polling the backup except when
the primary feed is down. Or you could call them all the time, but only
use them for outbound news, for quicker news propagation.
More importantly (in terms of this being acceptable to the remote admin) you
could reduce the remote admin's headache level by writing a few scripts that
entirely automate his end of the deal. He could set up a mail alias that
you could send start and stop messages to that would turn batching on and off.
You could also automate your end. Have a cron job that checks recent news
activity, and if there is none, automatically start up the backup feed. It
could as easily turn it off again when the primary come back on line.
Are there any major holes in this plan? I know that there will be LOTS of
duplicate news from the primary when it comes back online (unless it was
crashed, not just modem-dead), but that's OK. We'd also miss up to a day's
worth of news but that's a lot better than nothing. And I know about ihave/
sendme and I can't use it- it's too much to ask for, and too costly, for a
setup that will be used maybe 2-3 times a year.
BTW, while I'm asking, is there a site in New York City (718 or 212 area codes)
that's willing to do something like this for us, if we do the work? We have
a telebit and will do all the calling.
Thanks,
---
Alexis Rosen
Owner/Sysadmin, PANIX Public Access Unix, NY
alexis@panix.com
{cmcl2,apple}!panix!alexishenry@zoo.toronto.edu (Henry Spencer) (06/29/91)
In article <1991Jun28.112207.939@panix.uucp> alexis@panix.uucp (Alexis Rosen) writes: >What we'd like to do is set up a backup feed. Can anyone think of any serious >problems with the following plan? You can use existing facilities to get more or less the same effect; many people use ihave/sendme links for backup feeds. (This would work better if there were a delayed-ihave/sendme facility; it's easy to tinker one up, and an "official" implementation is in the works.) -- Lightweight protocols? TCP/IP *is* | Henry Spencer @ U of Toronto Zoology lightweight already; just look at OSI. | henry@zoo.toronto.edu utzoo!henry
alexis@panix.uucp (Alexis Rosen) (06/29/91)
henry@zoo.toronto.edu (Henry Spencer) writes: >alexis@panix.uucp (Alexis Rosen) writes: >>What we'd like to do is set up a backup feed. Can anyone think of any serious >>problems with the following plan? > >You can use existing facilities to get more or less the same effect; many >people use ihave/sendme links for backup feeds. (This would work better >if there were a delayed-ihave/sendme facility; it's easy to tinker one >up, and an "official" implementation is in the works.) Hm. I know about ihave/sendme and decided that setting that up, when it will only be user for two or three two-to-six day periods in the year, is a big waste of resources. It's also less likely to be acceptable to an admin who's worried about conserving resources. Is there a flaw in the first plan? And, could you please elaborate a little on the "delayed" ihave/sendme? I'm not too clear on what you mean. Another vague (and more difficult but effective) option comes to mind: the backup feed could create batches based on timestamps in the active file. You'd still miss some news, but not all that much, if you allowed for a slop factor of, oh, maybe one day. --- Alexis Rosen Owner/Sysadmin, PANIX Public Access Unix, NYC alexis@panix.com {cmcl2,apple}!panix!alexis