[PROXYPER] Personal Proxy 304 Q&A
jlawson at bovine.net
Sat Feb 13 21:17:33 EST 1999
On Fri, 12 Feb 1999, Ivo Janssen wrote:
> On Fri, 12 Feb 1999, Petr Novotny wrote:
> > (-) In a crash, since the done block are in the memory and not on
> > disk, they're lost. (280 proxy was much better handling that.)
> Is this true???? I thought 280 kept ALL blocks in memory (can be a
> lot on a big proxy) while making a diskimage of it and that 30x kept
> less blocks in memory. Anybody on the coder-side on this?
The 300+ proxies store a small number (~10 packets) in memory, with
the additional packets stored within the buffer files. This applies to in
and out buffers. The ones that are held in memory are intentionally not
backed-up to the buffer files. They will be written out when you shutdown
the proxy properly.
> > (-) When our LAN is not online and proxy wants to fetch/flush, it
> > ignores requests from clients. (Hell, what's the proxy good for
> > then?) I can post here logs and stuff. (It seems that is hangs in
> > gethostbyname() and refuses client connections. My setup is
> > caching-only named; if proxy resloves the name, it asks the local
> > named which in turns tries to fetch the info from the - now
> > disconnected - Inet and times out too late.)
> WHY should a proxy want to resolve a name?
Resolution is necessary for outgoing connection attempts. If you
want the proxy to NOT attempt to make outgoing connections while you
are offline (and thus NOT attempt to make DNS resolves), then set the
proxy connectivity mode to "offline" and simply send a SIGALRM signal
whenever you know you are online and want the proxy to flush.
The "problem" of buffers getting "locked" with the 300+ proxies and the
new need to unlock them should not be considered a weakness. It is
designed as a protection mechanism to attempt to eliminate conditions in
which users accidentally start up two instances of the proxy, and have
them both transmit the same completed blocks upstream, which was an
occasional problem for us, which resulted in duplicated done blocks being
reported, and incoming new blocks getting lost.
The issue of buffers getting corrupted has also been raised. Although I
believe it is still very rarely possible for buffer corruption to occur,
which *may* cause blocks to be lost if they are attempted to be added to a
corrupted buffer, this should be rare in the current (ie: 304) build.
Autorepairing mechanisms have been added, which will typically catch
corrupted buffer issues. Regular manual repairs of the buffers (using the
-repair option) should be a part of your system maintenance schedule.
Jeffrey_Lawson at hmc.edu jlawson at bovine.net bovine at distributed.net
Programmer, Developer, Mascot, Founder of the largest computer on earth!
Don't waste those cycles! Put them to use! http://www.distributed.net/
To unsubscribe, send 'unsubscribe proxyper' to majordomo at lists.distributed.net
More information about the proxyper