[Home]RoboRumble/ProtocolDevelopment

Robo Home | RoboRumble | Changes | Preferences | AllPages

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

Result

Methods

Parameters common to all methods

requestBattles

returnBattles

releaseBattles

renewBattles

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.


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

Cons

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.

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


Robo Home | RoboRumble | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited May 18, 2006 21:33 EST by Florent (diff)
Search: