Multiplayer Coding/Issues

[F_Smith]

Hi, Guys:

Absolutely we should extend HTTPServlet, I think.

And I also don't mind using the Unix shell, but I've got to warn you, I'm a Unix idiot. But I definitely am interested in gaining some working knowledge, so this is great. I just bought a copy of Red Hat Linux, and am going to install it on an old machine next week, at work, for the experience, and for a test bed.

That will help me here, won't it? Or am I mistaken?

[robin]

quote: Originally posted by F_Smith on 10-28-2000 12:16 PM Hi, Guys: Absolutely we should extend HTTPServlet, I think.

NO, NO, NO, if you extend _any_ servlet class you _must_ use a webserver to fire them off, this means having to handle cgi/http streams (both in client & server). What we are trying to build is a _server_ (like apache, gets socket requests and replies on that socket (with http packets in this case)), and hads a main method just like a normal java program.

NB. Sorry i've been silent for a while (this is due to my house been flooded by the river Kennet).

[F_Smith]

Robin:

I'm sorry, I don't understand.

Why do we want to build our own server, instead of using a servlet?

We'll need to use a web server -- I like the Java Web Sever, personally, of course. But isn't that better than having to write all that server code ourselves? I don't understand the gain of using sockets in this case. I was thinking we'd be using doGet and doPost to pass data to the servlet, and just printing any response data (serialized) to the HTTPServletResponse, via a PrintWriter.

Are there reasons this would not work?

I've written a chat server and applet, it runs on our internal Project Office web page and gets used regularly. I've got the code for that, if we absolutely need to build our own server.

And later, I was absolutely hoping to migrate to a Bean architecture, which will absolutely require an App Server. Does this sound like a good idea?

[Bernd Wieboldt]

Hi guys,

quote: Originally posted by robin on 11-01-2000 08:02 AM NO, NO, NO, if you extend _any_ servlet class you _must_ use a webserver to fire them off, this means having to handle cgi/http streams (both in client & server). What we are trying to build is a _server_ (like apache, gets socket requests and replies on that socket (with http packets in this case)), and hads a main method just like a normal java program.

Another question: is the protocol that clash clients and servers will use to communicate already defined?

This definition has - in my opinion - a higher priority than the question about how to implement it. Before this definition is made, we just can't decide which way of implementation is used best. Maybe we decide to use servlets, make our definition and see we'll need a customized web server. To prevent this, we should *first* think about how clients and servers communicate and *after that* decide how to implement that.

If this definition is already made, I would be glad to be given a link to it (or get a mail with i).

[robin]

quote: We'll need to use a web server -- I like the Java Web Sever, personally, of course. But isn't that better than having to write all that server code ourselves? I don't understand the gain of using sockets in this case.

Well think of what the web server is actually doing. It takes socket requests from clients (you with your browser) and loads the requested (usual a file, of a file stream i.e. a CGI program), then sends that resource back down the socket to you. In-between those transactions are conversions to and from the http protocol. Well we don't want to use the http protocol cuss it would require object string parsing (heavy) and why take the extra load of a web server just to avoid socket routines?

quote: I was thinking we'd be using doGet and doPost to pass data to the servlet, and just printing any response data (serialized) to the HTTPServletResponse, via a PrintWriter. Are there reasons this would not work?

No, but you could do that faster in perl

quote: And later, I was absolutely hoping to migrate to a Bean architecture, which will absolutely require an App Server. Does this sound like a good idea?

Yes, I like this idea, do you think we could use beans to have a kind of 'plug-in' data processing, with the beans carrying the AI etc routines (bit I'm currently think Jini would do a better job of this)?

[robin]

quote: Another question: is the protocol that clash clients and servers will use to communicate already defined?

No.

quote: This definition has - in my opinion - a higher priority than the question about how to implement it. Before this definition is made, we just can't decide which way of implementation is used best. Maybe we decide to use servlets, make our definition and see we'll need a customized web server. To prevent this, we should *first* think about how clients and servers communicate and *after that* decide how to implement that.

I'g agree, but was thinking that since the client will be java, we can just send objects (i.e. without protocol) since its dead easy for the client to define the _type_ of an object.


I'll send you a key/password so @ least you can access the CVS rep. Check out http://www.clash.ukshells.co.uk
for help on how to use the cvs server....

[F_Smith]

The http protocol is plenty fast enough for our purposes, isn't it? I've got some servlets doing heavy doPost parsing, and its very, very fast. The parsing delay is only a few dozen milliseconds.

I agree that there it might be possible to get slightly faster response time using some other methods, but the Web Server actually does more than just manage the socket connection, giving us other features that will be big bonuses for enhancement -- like session tracking and Bean managment.

From what I understand of 'Jini', it's design for running on small hand-held devices. I'm not sure I understand why it would be useful for the AI. Can you help me out with that?

I was thinking RMI and/or Corba, perhaps. RMI Allows us to use the processor on the client to actually process the AI methods on the client.

[F_Smith]

Bernd:

Yes and no.

The game data will all be held in a single object called 'GameData', which will be shared by all players.

The idea I was working with at this point is that the clients build 'TurnHandler' objects from all the orders given by the player. We then send that data to the servlet via a doPost. The servlet processes the turn, applying the turn orders to the game database, and then builds a new 'GameData' object, then serializes back out to the client the new 'GameData' object.

Does this sound workable?

[Bernd Wieboldt]

Am I right in understanding that all the turn handling will be done in the server? If so, will all commands be sent to the server, enabling all players acting together, or will a full turn be sent to the server, most certainly forcing all players to make thrie moves separately? Two more questions for the list. I still have no access to the cvs repository (but already sent my key to robin), so excuse me if I ask a silly question: are you alredy at the point where I would place the ongoing discussion about which protocols to be used? If not, do you both agree in the way I suggested us to work?

[Bernd Wieboldt]

I'm sorry I left it out in my first reply, yes, it sounds workable.

[robin]

quote: The http protocol is plenty fast enough for our purposes, isn't it? I've got some servlets doing heavy doPost parsing, and its very, very fast. The parsing delay is only a few dozen milliseconds.

-The communication relationship is wrong; (generally) webservers tie up the socket port. Clients are required to wait for a response from the server. When handling simultaneous updates from multiple clients this delay becomes a bottleneck.
-If we used a webserver the whole game server would be threaded for each request, this would be very heavy.
-Not all systems easily support webservers.

quote: I agree that there it might be possible to get slightly faster response time using some other methods, but the Web Server actually does more than just manage the socket connection, giving us other features that will be big bonuses for enhancement -- like session tracking and Bean managment.

All of which sould be doen via reflection classes.

quote: From what I understand of 'Jini', it's design for running on small hand-held devices. I'm not sure I understand why it would be useful for the AI. Can you help me out with that?

Jini uses a sub set of Java, a foot print if you will. It is light and optimised. Basically it allows the formation of a generic-processing network. It's a little complex, but the idea is that we have a core of Jini functions attached to a RMI server with access to the database server. Then We can 'plug-in' functions as they are defined (both background and client request).
This help AI, because you can use it to defines a backbone for distributed processing, allowing us to handle very complex models away from the main game data processing (i.e. we could have a sub set of clients simulate a years weather data).

quote: I was thinking RMI and/or Corba, perhaps. RMI Allows us to use the processor on the client to actually process the AI methods on the client.

Jini is based on and incorporates CORBA/RMI.

[robin]

quote: Originally posted by Bernd Wieboldt on 11-04-2000 01:44 PM I still have no access to the cvs repository (but already sent my key to robin)

Yes can people please stop sending me _pgp_ key sets, i need ssh RSA public keys (use ssh-keygen)

[Bernd Wieboldt]

quote: Originally posted by robin on 11-04-2000 11:31 AM I'g agree, but was thinking that since the client will be java, we can just send objects (i.e. without protocol) since its dead easy for the client to define the _type_ of an object.

Perhaps I was not completely exact in what I wanted to say. I didn't want us to decide wether to use HTTP or something else. I wanted to know if it's already defined what data are to be exchanged, how this data are summarized in the 'sender' client, how they are brought into play in the 'receiver' clients and so on. It would fit nicely if the summarized data had the same form like the AI output, since we just had to give the data to Mark (sorry, to the 'executive part' of the AI). So, do we know what data to transfer? Do we know how to summarize them? Do we have a 'floor plan' which tells us where we have to collect them? I see models which produce the same data for all players, for example map generator and disasters: all players will play on one map and all players will see the same disasters in the same place (even to the canadians Chernobyl is clearly in what used to be the USSR). Will this parts run on one client, the server or someway else?

That is, in my eyes, more important than to decide at what OSI layer we transfer them. I agree with you in that it is pointless to do any data unneccessary protocol converions ourselves, for example encoding the content of an object into an HTTP stream. Sockets allow us to conveniently communicate from layer four to layer four, so using them (and avoiding full three layers of the model which are occupied by HTTP) seems OK to me.

Our next task should be completing the above list of questions and answering them. If this is done, we can look at our informations and decide if we are ready to start coding. If we are, we can decide what to code. Since there is no 'true' answer at the moment, the ongoing discussion is to be placed at that point. In my eyes, of course.

[Mark_Everson]

quote: Originally posted by Bernd Wieboldt on 11-04-2000 01:44 PM Am I right in understanding that all the turn handling will be done in the server? If so, will all commands be sent to the server, enabling all players acting together, or will a full turn be sent to the server, most certainly forcing all players to make thrie moves separately?

I hope I'm answering your question...
Player and AI turns are all done simultaneously. Any server etc. plan needs to support that. This has already been discussed before here, so that's why I'm afraid I may have not gotten your question right.

[robin]

I have added all code that i have to the cvs repository, i need a copy of the current client code (@ whatever state its @). People really now need to be using cvs so that we all have a current copy of the code, please send me you keys or i will make you one and send it to you (instructions on cvs can be found @ www.clash.ukshells.co.uk).

Is there any code documentation for the client, is it worth having a policy on this??
I guess its worth having some design diagrams so people know what object does what, any preferences over format (SSADM??)?

For now, i think we should just get the server doing the two basic functions (recording movement, resolving conflict).
Basic flow:
Client: completes turn, user hits 'End turn button';
Client: Send object* containing the position of all units, status of citys and conflicts this client has _caused_*;
Server: Get Turn packet (TurnPacket);
Server: if have TurnPacket from all clients, start turn processing***;
Server: Turn processing....
Client: Request new world data packet;
Server: if TrunProcessing complete, sent WorldPacket else refuse request;
Server: Send deny;
Client: Wait b4 trying again;
Server: Turn processing....
Server: Turn processing complete;
Client: Request new world data packet;
Server: if TrunProcessing complete, sent WorldPacket else refuse request;
Server: Send WorldPacket;
Client: get WorldPacket;
Client: update map;

* Example object format (PS this is an _example_ please don't comment on syntax!):
public class TurnPacket implements Serializable
{
Vector unitPositions = new Vector(); //vector of {object unit}.
Hashtable cityStatus = new HashTable(); //hash of {cityID}->{object city}.
Vector conflict = new Vector(); //vector of conflict object.
}

public class Unit implements Serializable
{
int unitUniqueID; //an unique id assigned to each unit, defined by client: clientID.unitID
Position unitPosition; //where on the map the unit is (now).
}

public class CityStatus implements Serializable
{
int cityUniqueID; //unique city ID defined by the client: clientID.cityID
CityData cityData; //city data??
}

public class Conflict implements Serializable
{
int unitUniqueID; //same as Unit.unitUniqueID
Position position; //disputed map position
}

** A client causes a conflict by moving a unit onto the same position as another non-allied players unit or city.
The conflict is only valid if the other players unit or city is still in the same place @ the end of turn (i.e. all players will be moved b4 resolving conflict! If two non-allied players collide @ end of turn (you moved you unit to the same place as another player) then a conflict occurs.

*** Turn routines not yet defined!

**** Example WorldPacket format (PS this is an _example_ please don't comment on syntax!):
public class WorldPacket implements Serializable
{
Vector unitPositions = new Vector(); //vector of _all_ {object unit}.
Hashtable cityStatus = new HashTable(); //hash of _all_ {cityID}->{object city}.
Vector resolvedConflicts = new Vector(); //vector of conflict results.
}

public class ResolvedConflicts implements Serializable
{
int unitUniqueID; //same as Unit.unitUniqueID
Position position; //disputed map position
boolean survived; //is this unit still alive?
}