[rc5] rc5v2 full of bugs and misfeatures (long)
fgouget at club-internet.fr
Tue Jul 15 08:10:24 EDT 1997
I'm sorry, really sorry. I know you may be working hard but
*THIS IS A FLAME*
(but an argumented one)
What triggered the flame mode ? This week-end, a 4 day week-end, I set up
the rc5v2b2 clients on 13 machines at the office so that they would crack
keys. I had tested the clients during the week and I must say I was a bit
afraid that would not run properly. I was right. I went to the office
twice over the week-end the situation was all fucked up to say the least.
End result the first day I computed 48 blocks when I should have processed
624 of them. I really feel like I've wasted my time.
* Problem 1 - random blocks
You advertise the clients as being able to create random blocks. This is
wrong/does not work (remember I use build 2). When the client first cannot
connect to the server (the office has no connection to the Internet) it
generates a random block. When after this random block it still cannot
connect to the server it loops indefinitely on the error "Network::Open
Error - Sleeping for 15 seconds". I have already reported this bug but no
one seems to care.
* Problem 2 - huge log files
The previous problem gets logged. This means that the log files get
huge. On the home partition there was 9MB left. When I arrived this
week-end the NFS server was screaming "/home partition full". 9MB of log
files endlessly repeating "Network::Open Error - Sleeping for 15 seconds".
There was also another message saying something like "Buffer is locked 3 -
waiting 1 second". I don't konow if this one was caused by the file system
being full or if it was caused by a bug in the sharing of buffers (I share
some of them across different Unices and Win32 hosts). Such messages
should not be repeated in the log file. Write them once and after that put
a count to inicate how many times they were repeated.
If I had not cleaned up this mess my administrator would have killed me.
* Problem 3 - too many network errors
When fetching and flushing blocks really too many network errors occur.
I can't imagine how bad it would be if ftp or web browser displayed
"network error please restart" every 500 bytes or so ! Why don't I like
network errors ? Because when I report the office blocks on my home
computer I must report about 650 blocks and fetch 650 others. If a network
error occurs every 5 to 15 blocks I must restart the clients 5 or 6 times
multiplying the total time by as much. I can't believe that Internet
communications are so unreliable so there must be something wrong either
in the protocol or in the way the clients handle the network
communications (maybe the timeouts ?). It's better than the V1 clients
* Problem 4 - buffer limited to 50 blocks
I can only buffer 50 blocks. This is a mere 24 hours worth of work. This
is really insufficient for week-ends. Furthermore I don't want ot go
through the process of stoping all the clients switching the files,
restarting the clients, reporting the blocks every single day. So either I
can buffer 200 blocks or I will compute random generated blocks (thus
wasting 5.5% of my computation time, I know).
Why is there this 50 blocks limit anyway. It won't prevent me from
getting 600 blocks if I want to anyway. It will just make it a bit less
practical. Unlike SolNet you don't try to keep a limited number of
"active" blocks since you accept random blocks and don't impose a
computation time limit. So why such a limitation ?
* Problem 5 - rc5v2b2-decunix32-alpha-ev4 processes only one block
rc5v2b2-decunix32-alpha-ev4 would process one block and quit. For this
setup the buffer was shared with a rc5v2b2-sunos414-supersparc client.
I had to invoque the rc5 client like this to get it to work:
while true; do rc5v2b2-decunix32-alpha-ev4;done
* Problem 6 - kill -9 required in error cases
When the error "Buffer is locked 3 - waiting 1 second" occurs only kill
-9 will stop the client. In the signal handler you should count the number
of ^C and exit immediately when reaching some limit. Not really pratical
when the server is almost dead because of a full filesystem which is also
precisely a case when this error occurs !
* Problem 7 - do not delete the buff-* files
Since I have many hosts, each host having its own buffer I have the
+-buff-in.rc5 -> ../buff-in.rc5.$hostname
+-buff-out.rc5 -> ../buff-out.rc5.$hostname
Now when the client has processed all the blocks it deletes the buff-in
file which in this case amounts to delete the link. It would be much
better to keep a 0 byte (or rather 8 !) file that way I would not have to
recreate the link every time. (This seems not to happen when the buffer is
shared since in that case the file size does not change even after when I
bring it back home).
* Problem 8 - lack of command line options
Ini files are nice to simplify the command line. But when you have
multiple hosts and want to have customised options for some of them
creating an ini file just for that is clumsy. Command line options would
be more adapted in that case. For instance sharing a buffer file while
retaining a separate log file requires that you create a separate ini
Now on to problems of lower importance:
* Problem 9 - log file format
The log file format is not very practical to parse because informations
related to one block are writtent on different lines. The time at which a
block was started is on a first line, the time at which it was finished is
on a second one and the keyrate and processing time is on a third one. So
besides making log parsing more difficult it also prevents the sharing of
the log file between different hosts or may result in a log file that
cannot be automatically analysed as you may get something like:
start block 1 start blcok 1
start block 2 or start block 2
end block 2 end block 1
end block 1 end block 2
* Problem 10 - SolNeters remember the "-p" option ?
The SolNet allowed you to specify a "-p" option which told the client to
pause before trying to connect to the Internet. That way users having
dialup connection and paying the phone by the minute could control when
their client would connect to the Internet. Such an option would be nice.
Or you could replace it with a command line options saying "no network" so
that the client would never attempt to connect and flushing/fetching would
be done by running another instance of the client without this option.
This way no need to have two ini files (oooh, only one ini file needed,
you're going to be soooo sad!).
* Problem 11 - v1 personal proxies source
Why isn't the v1 personnal proxy code available ? Since all that is
needed to build a spamming machine is in the v1 source there is no
reason not to release the v1 proxy code.
* Problem 12 - secure public network protocol
When will the bright suggestions made by Honza Pazdziora and Tim Charron
for a secure and publicly known protocol be implemented ? Is there nybody
working on this ? Maybe this could be started publicly and not as a secret
project of the RC5 development team.
* Problem 13 - v2 personal proxies, client build 3
When will the v2 proxies be out ? On the We bpage you say something like
"The V2 proxies will be out real soon now". This has not changed for at
least two weeks !!! Will the new proxies support e-mail gatewaying ? The
build 3 clients were announced for late last week-end. We are on monday
(morning now) and all I see are the build 2 clients. The stat pages are
still in the works and I didn't see that much change (unless all we see
are the old stats with the new log format and the new stats will get out
later. To re-use a slightly modified SolNet slogan "I bet you cannot do
better stats than SolNet. Prove me wrong !". Maybe it's time to admit that
you need more developers ?
* Problem 14 - benchmark mode requires ini file
Even in benchmark mode the client first wants to get its ini file ! This
is absolutely unnecessary.
Oh, by the way, this is the ini file I use at the office. Nothing fancy
as you may see:
id=fgouget at club-internet.fr
fgouget at club-internet.fr http://www.mygale.org/~fgouget/
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5