RoboRumble/ProtocolDevelopment

Server API

I think the first thing to do in developing a new RoboRumble protocol is deciding on the API. If we will use SOAP/XML, a HTTP servlet or our own TCP protocol will not affect the functions the server makes available to the clients. Therefor this part of the specification is only about what to send and not how. Feel free to edit the proposal if have some good ideas.

Structures

Battle

• id : int
• width : int
• height : int
• rounds : int
• robots : String[]

Result

• scores : int[][]

Methods

Parameters common to all methods

• username : String
• password : String

requestBattles

• Parameters
  • count : int
  • timeout : int
• Returns
  • timeout : int
  • battles : Battle[]

returnBattles

• Parameters
  • battles : Battle[]
  • results : Result[]
• Returns
  • accepted : boolean[]

releaseBattles

• Parameters
  • battles : Battle[]
• Returns

renewBattles

• Parameters
  • timeout : int
  • battles : Battle[]
• Returns
  • timeout : int
  • battles : Battle[]

Unresolved Issues

The above proposal is not complete. There are probably many things that were missed. Please add any issues you see to this list and discuss them.

• How should clients know where to download robots?
• Should the server maintain the participant list?
  • IMHO deciding who's in the rumble is not the client's task. And a nice JSP or Servlet for managing the list would be a nice feature. Strider
• How should the server know which competition a bot is in?
  • One option I see is having the server download and check the jar when it is added to the rumble. Strider
• Should the server return a status code from each method?
• The Result structure need refining
  • I didn't even look at what Robocode returns after a battle when I wrote the proposal. Strider

---

Transport

Here we can discuss how the client should communicade with the server. Feel free to add comments and other types of transport.

[Web Services]

That is [SOAP] over HTTP POST. The server must have an application server with an SOAP implementation. A free solution is [Tomcat] and [Axis] but there are certainly other.

Pros

• It's a standard protocol specially designed for things like this.
• Almost no network code has to be written.
• It uses HTTP so it should work through proxies.

Cons

• The client will depend on some third party library.
• XML is quite verbose and generates a bit more network traffic.

You can download an implementation of the proposed API as a web service here: http://www.daniel-nilsson.com/stuff/rr2-proposal_1.zip -- Strider

---

Discussion / Comments

Great to see there is people interested to enhance RR@home. The current version of RR@home is a little bit messy, but there are some design decisions I'd like everybody to be concious so we don't have to think it twice.

• RR@home uses only HTTP for 3 reasons: It is easier to deal with security (no problems with firewalls nor hackers trying to reach client computers), it makes people more confident to use the client (personally, I don't like untested software using strange ports and protocols installed on my computer), and it is easier to develop and maintain.

• When we set it up, it was not clear were it would be installed nor which would be the definitive setings. It is the reason RR@home reads the participants from one page, and posts the results into another one. Also the Wiki was an easy place to maintaint the participants list. If you change it, you will need to set up an interfase to maintain the participants file. In the current design the server was just a silly data receiver (all logic was on the client). Of course, now that thinks are more stable, It would be a good idea to take advantage of a good server (ie. the server is the one that removes old participants).

• All the design is oriented to allow the clients to work without need to connect to the server (and to minimize traffic). I think it is important because it is not clear everybody has a connection 24h open. So the clients run battles the best they can, and then the server eliminates the ones that are not useful. Also, if the server is down, the clients can work and then upload the battles when it gets up again. Aso, it avoids unnecesary work in the server (it was a concern when we set up RR@home, because we didn't know how much work would it represent for the server). The initial idea (no direction from the server) changed a little bit (now there are some priority battles and so on, but the aim for simplicity, decentralization and self-coordination is good I think.

• With the current design, you can have as many competitions as you want. To set up the StrongestBotsRumble you just need the server to generate periodically (ie. every week) a Web page with the list of participants and let the clients to download it and run the competition.

• Be careful with databases, XML, and all this stuff. It makes difficult to find and setup a server to run the RR@home (how long would have taken to create a backup server for RR@home if it had used MySQL?, XML, direct connections and some other funny things?). Also I think one of the great things of the current design is that (even with a messy code) everybody can understand it and collaborate (ie. developing new servlets to analyze data) just because it uses plain text files and everybody understands them (will it be true with XLM or SQL?). Of course, performance is the price you pay for it :-)

Summaryzing: All RR@home was made keeping simplicity in mind (just make it complex when the experience has demonstrated it is necessary) and to minimize effort and knowledge needed to create/maintain it. I think this principles should stay in any new release of RR@home.

Again, it's good to see people dedicating time and efforts to improve it. My best wishes for the project.

-- Albert

Cool! I think the simplicity of the current client / server has proven very useful. And though we have had some problems with data file corruption the system has proven very robust and able to heal even hard blows. The use of files instead of a database makes it simple to setup and maintain to a degree. I can't say that I see it impact performance in any degree really. Even when there were 10 or more clients competing on delivering battles as fast as they could the server wasn't even using fractions of the available capacity. In fact the server was itself busy running the RR@H client, testing new versions of CassiusClay, browsing the net and my daughter was playing her games on it (Barbie Horse Show Adventure being the favourite). On the other hand I can't see that using SQL and / or XML would make it any harder to set up. There are free and easy to use tools for it. And both SQL and XML can help us build solutions that would be hard to do with stuff burried in a sea of files. A dynamically updated PremiereLeague? comes to mind. I also don't see why we should let one or two machines on the net lacking a constant connection stear the design descisions. Let's assume the server is always up and that the clients always are connected to the net. It will make things more fun and easier too. -- PEZ

And, as I said somewhere else. We can make a local server to proxy when the client machine is offline. -- PEZ

---

What do you think about a completly new client/server using Axis?

Ofcourse that means a rewrite of both the client and the server to fit the new protocol. I volunteer to write a new client (I'we started but is currently wating to see what protocol I should use). Someone must adept the server too.

-- Strider

I'm rewriting the server *anyway*. Please see /Development for more info. I would be happy to write the server side of version 2 of the RR@H protocol. --David Alves

Yeah, and Strider is rewriting the client *anyway*. I think it sounds excellent to use a web service framework for the task. I'm in love with http too as transport. The overhead in traffic is neglectable I think. Though I don't know nothing about Axis. I guess I'll have to read up on that one to know if I think it's a good choice. -- PEZ

Strider is rewriting the client *because* he wants to change the protocol. I am rewriting it for a different reason, hence "anyway". :-P --David Alves

Well, at first I wanted to rewrite the client just to clean it up. Then I found out the the protocol also needed a cleanup and now I want to rewrite the client for both reasons :) -- Strider

---

I updated this page with a new proposal and removed a lot of comments that I felt was no longer relevant. -- Strider