SB v3 in Active Development
The next generation of the Seventeen or Bust network, or Version 3, is under active development. I'll cut right to the chase. First, some design goals.
Open development.
The new system will be almost entirely open. Like distributed.net and most other DC projects, parts of the code will still be kept closed for security, but the vast majority of it will be released publicly. We want the development process itself to be open, too. At some point, hopefully sooner rather than later, we'll set up a development web site with news, anonymous CVS access and, I'm guessing, a Wiki. People that have been developing third-party tools for SB will have a chance to actually contribute to the code itself. It's better for us, and we think it's better for you too, but that's up to you guys to decide. We'll probably set up a sub-forum for development and testing here on FreeDC. In addition to being morally satisfying, I think opening development will be a lot of fun.
Modularity.
We want the client to be extensible. Right now, for example, the sieving and P-1 factoring sub-projects are sub-projects because the current client isn't able to accommodate anything other than Proth testing. We don't like this. The new client will use a plugin-based architecture to do its work. When you download the client, you'll be downloading a framework, which contains the user interface, network code, disk cache code, etc., that can run regardless of what kind of work the client is actually doing. Then the Proth testing code will become a plugin. The sieve code might become another plugin, although we have not yet approached the coordinators of those projects so I can't say that with any certainty. Same with the P-1 factoring sub-project.
Portability.
This next bit is going to shock some people. Please sit down before continuing. Are you sitting? Good. We're writing most of the client in Java. We know it's hard on resources. That's why I didn't say “all” of the client. The worker plugins make use of Java's “JNI” (Java Native Interface) support. It allows Java code to interact with low-level native code, like C and assembly. Using this, we can pull of a highly-portable and structured client framework without sacrificing performance. Each worker plugin (say, the Proth test plugin) will be available for several operating systems. For example, when you download the Windows client bundle, you get the Java framwork, plus the Windows native version of the Proth test code, which is of course written in assembly. When you download the Linux bundle, you get the Linux version of the plugin instead, and so forth. So, even though the worker plugins still have to be ported from platform to platform, the framework itself will only need to be written once.
Exploration.
We want to explore new approaches to distributed computing. As far as we know, no major DC project has ever attempted such a modular, portable design. I know it may sound crazy to some of you, but I really think it will work out very well.
As far as a time table for development, we don't really have one at the moment. But we do have some broad stages in mind – an order in which we want to do things.
The first stage is to complete the skeleton of the client framework. We'll need to re-implement the networking code, configuration, disk cache code, and so on. We'll also need to convert the current number-crunching code to a JNI library so that it can be used as a worker plugin. We will NOT be writing the GUI right away – the initial versions of the v3 client will be console-only.
We'll also need to rewrite, or at least seriously modify, the server, to accommodate new features being introduced into the new client.
When the console-only skeleton client and server are done, we'll make a “public” alpha release. The new server will run on a different port, and anyone interested in doing so can test out the new client.
Throughout alpha testing, we'll be working on the user interface, JNI worker plugins for different platforms and, possibly, different tests (sieving? P-1 factoring?). The server will no doubt gain some meat in this second phase as well.
Once the client's user interface and more robust features are finished, it'll go into beta release. During beta testing, we'll be working on the public web site and the statistics engine. We have some ideas of things we can do to make the stats a lot more accurate, more interesting and more informative. We'll also take this opportunity to make the web site more attractive to potential non-technical users.
Finally, with the web site modifications done and having had a bit of time for beta testing to weed out the bugs, we'll do the official 3.00 stable release.
That's about all I need to say about it right now. I'm sure a lot of you will have a lot of questions and I'll try to answer them as best I can.
--
David Norris
danorris@seventeenorbust.com
Re: SB v3 in Active Development
Quote:
Originally posted by kugano
As far as we know, no major DC project has ever attempted such a modular, portable design.
Have you looked into cosm? It's a framework for distributed projects, used by folding@home, genome@home and EON.
Suggestions for 1.25 before 3.xx release
I am using the latest client but wanted to suggest some
small changes - before a full 3.xx. release
1) Could you provide more options of sending confirmation blocks.
Currently it seems to only be set to every block or end of test.
Specifically, I would like to send once every 5 blocks or so.
This would reduce the pauses between each block (which are
recently significant [30 seconds or so] and network traffic for
both me and more importantly for the main server.
2) Could you provide the ability to change the update frequency
for the status screen (windows version).
Currently it seems to update something once or more every second,
I would prefer once every 10 seconds, or even setable to minutes.
This would save some processor time, but also be less distracting
for indidivduals that like to keep the status box up all the time.
(For status updates, I personally prefer less granuality; for numbers
less decimals places displayed, and for time seconds not listed)
3) During the time the process connects to the main server and
send results it does not continue calculating. Anyway this can
be seperated out into a seperate thread. In my setup, it takes
oftens takes 10's of seconds or more to complete the connection
and communications....time spent not working on the project.
Provided that the main calculations are well optimized, optimizing the intra-block or wraping code might be the next best place to optimize overall
performance.
Regards,
