[PROXYPER] perproxy quits submitting work

david townsend cloacasoft at hotmail.com
Tue Dec 4 15:25:12 EST 2001


First, the easy stuff: Clients are all version 469, preferred blocksize
are all =33.  The missing blocks were all randoms.  For whatever reason,
the perproxy decided it wasn't going to do any network updates any more,
so whenever the in-buffer ran dry, it just stayed that way.

The internet connection is always there (unless our provider goes down,
which is rare), and as such, the proxy works great if it's running as an
application (I've been running it all day long, and it hasn't messed up
yet).  It just doesn't try to connect when it's running as a service.

Since yours doesn't detect your connection either, can we safely say
that that part just doesn't work?  Unless anyone else has any ideas,
I'll just go w/ your solution, buffer a buttload of blocks and start as
an app just before midnight UTC, and making a huge flush every Monday.


-----Original Message-----
From: owner-proxyper at lists.distributed.net
[mailto:owner-proxyper at lists.distributed.net] On Behalf Of Art Pannek
Sent: Thursday, November 29, 2001 8:18 PM
To: proxyper at lists.distributed.net
Subject: Re: [PROXYPER] perproxy quits submitting work

I have the same version perproxy running on NT4 with a modem
connection to the internet, and local ethernet. Ever since
this version came out, I haven't been able to characterize
why and when it stops detecting the dialup connection,
except that sometimes it wont detect it when I make a new
connection. Somehow it doesn't return to the initial startup
state. So, I start the perproxy service manually using "net
start dnetd" after connecting with the modem when I re-boot,
then I can hang up, and the next time I connect, it seems
normal. I have batch files to stop, copy ini file, start
again using task manager to use "expert mode" to get blocks
from the key server once a day ( around 2600 blocks, then
stop and restart with .ini file at 64 blocks). I also have
the modem connection start it's self so, I don't have to be
around. I sympathize. I cope by re-starting the service
twice a day using task manager.

Read the documentation about expert mode.

I have log files running once a day; sometimes I see long
stretches of failed connection attempts spaced about a 5
seconds apart, trying to connect to the same IP address.
This happens when the key server shuts down without being
removed from DNS. Seems to me that the error handling logic
in the perproxy should increase the time between attempts
for each failure, say 5, 5, 10, 15, 30, 60, 120, ... up to
twenty times before trying a different round robin IP
address for a key server. Or, switch to a different key
server right after the second failure.

As for your missing work of completed blocks, most likely it
was working on random blocks which just happened to be
already processed. That is most likely because of the
reprocessing to the key space. ( Seems like two years ago,
we were in the same key range. ) The second most likely is
you have old clients that discard partial packets if your
client blocksize=32 or less. The work around is to set
blocksize=33. See Bug 1475 in database. Get the latest

To unsubscribe, send 'unsubscribe proxyper' to majordomo at lists.distributed.net

More information about the proxyper mailing list