[RC5] DES 2 (in preparation of)

Colin L. Hildinger colin at ionet.net
Fri Jan 9 06:43:28 EST 1998


On Thu, 8 Jan 1998 21:23:27 -0800 (PST), Mary Conner wrote:

>I think I'm going to hunt down and shoot the next person who sends
>something both to me and the list.

I'll give you directions to my house.  :)  As long as it's set up
bass-ackwards like it is now expect a lot of it. If I hit reply it only
goes to you, if I hit reply to all you get two friggin' copies. 
Welcome to the hell of no "reply-to" in the header.  I warned people. 
And no, I'm not going to go remove a person from the address list every
damn time I send a message, sorry.

>On Thu, 8 Jan 1998, Colin L. Hildinger wrote:
>
>> Yeah, I understand that, but even if they just waited until we'd
>> finished the next prefixe it wouldn't be that big of a deal.  It would
>> still mean that said blocks were distributed several months in the past
>> until we get a keyrate several times what we have right now.
>
>It's no big deal to d.net.  Yes, we'd blow through those 50 blocks in
>nothing flat.  It's just that I hear a lot of people saying they run
>with bigger in-buffers or flush manually because, "I'd rather not have
>my machine doing random blocks if it can't get to a keyserver."  I want
>them to realize that if they do not let that in-buffer empty, then 
>when they eventually do have a situation where they can't flush, 
>they're going to be doing worse than random blocks, they're going to
>be doing blocks that have already been done, and then they'll come
>in here screaming their bloody heads off wanting to know why stats
>lost 50 of their precious blocks.

Yeah, well, I certainly understand your point here.  I do think that
putting a little more delay in between redistributing space will make
it more likely to not happen.  Possibly there's a way to make the
client deal with it?  FIFO would be one way but I think that would
cause problems with people using it on a shared network directory since
it would no longer just be a stack.  If it was FIFO then new blocks
would have to be added at the beginning of the buff-out file or blocks
for checking would have to be taken from the beginning.  I could see
this causing problems if there were many clients sharing it and it was
updating from the servers, etc.  Anyone else got any other ideas for
how the client could solve it w/o people manually cleaning out old
buff-in files by one of the methods discussed here earlier?



Colin L. Hildinger
------------------------------------------------------------------------
| Games Editor - OS/2 e-Zine! | The Ultimate OS/2 Gaming Page          |
| http://www.os2ezine.com/    | http://www.ionet.net/~colin/games.html |
------------------------------------------------------------------------
|	   The Official Unofficial AWE32 and OS/2 Warp Page            |
| 		http://www.ionet.net/~colin/awe32.html                 |
------------------------------------------------------------------------

CRACK 64-bit RC5 WITH OS/2 NOW!
http://www.ionet.net/~colin/rc5.html

--
To unsubcribe, send 'unsubscribe rc5' to majordomo at llamas.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list