[rc5] Re: MacOS issues in rc5-digest V1 #101

Kevyn Shortell kevyn at ricochet.net
Fri Aug 29 01:46:27 EDT 1997

Perfect example....my cat chewed through my network cable sometime today,
I came home and my trusty 9600 had stored over 200+ blocks that it had
done over the day, via the random key generation.

Plugged in a new cable, told it to go online, and it sent them all to
the proxy server.


At 11:01 AM -0700 8/28/97, andrew meggs wrote:
>>>What you can do is open the Network Settings dialog box, and put a zero in
>>>the in the blank where it says "Switch to offline mode after: ____
>>>consecutive network failures." Then they'll spend all eternity retrying on
>>>your dead network connection (with an accompanying decrease in performance)
>>>until the connection finally goes back online.
>>Will it do *any* random blocks until the connection comes back up, if you
>>set it to 0?
>Yes, it will. The decision to do a random block is a very simple test of
>"If I need a new key block and buff-in is empty at this particular instant,
>then make a random block." The MacOS network code is running in a
>completely separate thread of execution, attempting to refill the buffer
>before it runs out. Going offline disables that thread but the normal key
>cruncher keeps on going.
>>	I'm running Mac 2004 with FreePPP on  a PowerPC, System 7.5.5, 8Mb RAM.
>>Occasionally, the client crashes when flushing - it goes something like
>>1: Client completes clocks - tries to flush
>>2: Client calls FreePPP
>>3: FreePPP dials, and connects
>>4: Client gets proxy,says it is flushing
>>5: nothing happens - the client stops cracking, no menu options work, can't
>>swap to Finder, but the mouse still moves and the PPP connection is still
>The computer isn't actually hung, just stalled attempting to connect to
>connect to an unreachable proxy. If you go eat a sandwich or something,
>you'll come back to discover that it's finally given up.
>This is fixed in 2.005, which is basically done, but I've been too busy
>with "real work" to put it together.
>>Divide the keyspace into x area's, e.g. 16 (note, it better be more)
>>- - Every time the client reports blocks, the server also gives the area in
>>which the least blocks are solved.
>>- - When the client can't fetch blocks it generates blocks within the space
>>it got last reported as being least solved.
>A better idea -- build a bit of knowledge into the clients about the order
>of keys. When a random block is needed, look at the "highest" block
>checked, and pick a random block between that one and the "last" block in
>the keyspace, rather picking from the netire keyspace.
>>He's using a Power Computing MacOS (which I'm sure doesn't matter at
>>all), and, more importantly, connects to the internet (from home) with
>>OT/PPP and a scripted telnet session (available through OT/PPP). He's
>>using MacOS 8.0.
>I don't know; I've never been able to get ANYTHING to work over a scripted
>telnet session.
>>Just to share...
>>I was configuring v2.004 for my mac at work, and was having a similar
>>problem. This is gonna seem like kinda a silly question I realize, but is
>>he runing Thread Manager?
>The thread manager is built into system 7.5 and higher, so if he's running
>MacOS 8 then he's got it.
>Andrew Meggs, content provider                  Antennahead Industries, Inc.
><mailto:insect at antennahead.com>                 <http://www.antennahead.com>
>To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5'
>in the body.

Kevyn Shortell       |
kevyn at ricochet.net   |  BABYLON 5: Our Last Best Hope For Televised SciFi.

To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

More information about the rc5 mailing list