RoboRepositoryAtHome

Problem:

The current RobocodeRepository site is unstable and the hosts of it are not active Robocoders which means we often see outages of several days without having a clue as to why. The Robocode community needs something more reliable and so does the RoboRumble@Home infrastructure.

This is not to say I am ungrateful to the hosts of RobocodeRepository. The service they provide for free has been and is great and a big part of the reason why Robocode is still alive and kicking decpites the attention diet IBM is serving it. It's just that we need something more reliable and that we can trust delivers as long as there are active Robocoders. -- PEZ

I think we should not make an alternative to the existing repository, which is greate working for a long period. It'll become more confusing over the time. My suggestion is for the rumble bots we just replicate the bots to a free server in order to not overload the current repository. The replication can be than as a part of the server at once every day . -- SSO

I beg to differ. The confusion will go away once the new repository is established. And the problem is not just downloading from the repository when it's down. It's uploading too that can be halted. (Which is now was for a few days and I was frustrated when I couldn't let GloomyDark's black light shine onto the world.) -- PEZ

Possible solutions:

Time for a brain storm.

Just a bunch of web servers

Something like the mirroring networks that do the work for some open source and shareware software infrastructures? With this the wiki server (or maybe David Alves server?) could be where you upload bots and where you search for bots. Then it hands out links to live mirrors or something.

A peer-to-peer network

Maybe the RoboRumble clients can also listen on some port for requests to serve the jar for this or that bot? We would still need a central repository or two where we upload the bots to begin with. -- PEZ

It would be cool. I have no idea about how to implement it, but since it would be a (quasi) independent module it should be easy for someone experienced in it do develop. My concerns are:

• How do we make clients recognize each other?
• I feel very comfortable with the client as is, because it uses plain HTTP protocol to transfer the files. Would not messing with ports make the client more unsecure?
• I feel that having a peer to peer network would make uploading bots into the repository unnecesary, and I think it is great to have all of them in a single site...

Mirroring the RobocodeRepository or adding a second server that backups the repository, and allows people to upload the bots when the repository is not operative seems better to me. - Albert

I think a mirror is the more practicle idea. A peer to peer thing would be great though. You wouldn't need to have a central place to upload it. You just put it on the participents list, and then people will download it from your computer the first time. It is a great idea, but i don't think it would work in practice though. There are also security issues. Paul Evans could upload a new version of SandboxDT, I could then make a bot with exactly the same name, but with the function of sittingduck, and put it in my roborumble repository, then people will download it from me when they need it and get the wrong version. That would cause serious problems. -- Tango

Indeed, there are issues like that that would be a challenge to counter. And mirroring the current respository should be a workable way. If we solve the temporary uploading on a backup server. I think the RR@H client will need to be adjusted slightly to handle participants without a repository ID. This server can be used for such a backup i guess. But only as a backup, not for load balancing. -- PEZ

It's not a problem at all. Just set up the new mirror, tell me how the files are accessed (directly by name, using a servlet, etc.) and I'w change the client to access there also. -- Albert