Replacing Entropia's primenet server

[barcode]

Has anyone looked at boinc as a solution?

http://boinc.sf.net

[barcode]

Is anyone here?

[aga]

Originally Posted by barcode

Is anyone here?

At least me. But I see ~zero interest on the topic. Entropia server was down at least two more weekends after the last posts, but looks like noone cares.

So currently I'm in mood to just watch how the situation will evolve, maybe people will recover from holidays and pay more attention to the issue, or maybe replacing the entropia.com will become so important that I will be able to stop awaiting for opinons and ideas and go and implement my own. The offer for help I earlier worded still stays in effect.

After all, [re]implementing straightforward non-scaleable entropia-like server is an easy task and can be done and installed into a hosting account within 48 hours if real need arises. But really interesting, and I strongly believe most useful for GIMPS project in long-term, would be to create a flexible scaleable extendable solution. In fact, I don't care too much if anyone else interested in participating in the work, my experience allows to effectively handle such programming projects alone - but the I would definitelly like to have some assurance that after software matures enough to contain 'this, this and this' features, and passes testing, it will be factualy used. And I would really hate spending a piece of my life doing work that is not going to be appreciated (or used, which is in the end the same thing).

And so far, there is nothing like 'this, this and this' coordinated list exist, as if noone cares... here my message recursively repeats.

[Xyzzy]

I'd like to hear what Scott Kurowski has to say about all of this... It is his baby after all... I've tried to send him email several times but the emails bounce back... I'd also like to have Brad Bernard chime in with his thoughts...

[Prime95]

I care but I'm just too busy until Spring. Replacing the server will be my top priority for 2003.

Aga, I appreciate the offer of help and hope we can work together in the Spring. I agree that throwing something together real fast would be a mistake. If we're going to do this we'll need to do it right.

[aga]

Great! The Spring matches my own plans very well.

And I believe we will start with compiling stuff in this forum into a single document. So everyone's advised posting ideas and suggestions here without waiting for a particular date.

The key idea, as I see it: using multiserver configuration and/or proxies is not for spreading traffic or servers load (but eventually this might become important, too); instead, the primary issue is to ensure that GIMPS project does not wholly depend on a particular server or service, that there is no a single point of failure that can affect entire GIMPS. This is well in sync with the initial George's posting that started this topic.

[barcode]

Well I would like to offer up my time, skills and experience to the process. I have been working as a Architect and Developer for the past 6 years mostly within the Internet and distributed programing arena. My key areas of expertise as effects this project would be, I imagine: PostgreSQL, MySQL, Apache, Linux. My main skill however is Java development, what language are we thinking of writting the server application in?

[cperciva]

Originally Posted by aga

The key idea, as I see it: using multiserver configuration and/or proxies is not for spreading traffic or servers load (but eventually this might become important, too); instead, the primary issue is to ensure that GIMPS project does not wholly depend on a particular server or service, that there is no a single point of failure that can affect entire GIMPS.

Using a single server does not imply having a single point of failure which could effect the entire project. If the server is sufficiently generic -- built out of standard hardware, software (Apache etc) and a few easily installable custom scripts -- then it would be possible to replace it quickly if necessary. Given a few days of buffering on the part of client machines, even the complete failure of the server could occur without harm, as a new server could be set up before the client machines ran out of work.

Of course, this requires that regular backups are taken, but that's a much easier task than setting up several machines to serve in parallel.

[aga]

Originally Posted by barcode

what language are we thinking of writting the server application in?

My personal preference, and area of professional everyday job for the last years, is JSP/Servlets + MySQL + Linux (Slackware). This is a really nice stuff from performance, reliability, features/libraries, security, and portability standpoints.

Thank you for your offer, it sounds like that there is already a development/maintenance team. :) Good.

(We just need to figure out what we are exactly going to do :D )

[aga]

Originally Posted by cperciva

Using a single server does not imply having a single point of failure which could effect the entire project.

While that's a reasonable note, I disagree. Factually, it all depends on how we define 'failure' (and how we define 'harm' later). If hundreds users/computers are unable to get/return exponents and there are idle computers around, I think that's failure; do you? If such failure happens and GIMPSers are to wait days before the person(s) who can fix stuff will get down to it, that's even worse.

Originally Posted by cperciva

If the server is sufficiently generic -- built out of standard hardware, software (Apache etc) and a few easily installable custom scripts -- then it would be possible to replace it quickly if necessary.

If you are a well-funded business with a non-mission critical resource, yes. For GIMPS, who will pay for the 'standard hardware' when rush replacement becomes neccessary, and who will ensure that provided system software will suit the task best? Who will provide the quick turnaround service, for free and in long term?

Keeping a set of homogeneous servers is anyway a solution that provides better availability, better performance, better resists to DoS attacks, and best use of available bandwidth (if client-side software first tries to access topologically closest server). More tasking to create neccessary software? Yes, but the differene is not too large, and maintenance expenses are greatly reduced, both in terms of human job and hosting hardware.

Originally Posted by cperciva

Of course, this requires that regular backups are taken, but that's a much easier task than setting up several machines to serve in parallel.

As MySQL allows realtime replication, that is the most natural feature to use; it ought to be used notwithstanding if there is a single server or a dozen.

[barcode]

As MySQL allows realtime replication, that is the most natural feature to use; it ought to be used notwithstanding if there is a single server or a dozen.

I think PostgreSQL would be a better choice as it allows cross table transactions and sub-queries which are both very very useful things that MySQL doesn't allow.

I not certain why we need real time replication. Could you elaborate?