Bandwidth can be a problem, but I think we easily can get around it by only sending the variables in 'gamedata' that change back to the clients.

* * *

robin:

Absolutely, you are correct. The db does not need it's own box until traffic gets heavy.

I use Oracle 8i at work, just storing everything as a blob. They say Oracle promises that 9i, which is 100% java, will outperform any other database by 3 times or else they'll give you a million $$s. Have you heard that yet?

Sounds incredible, to me.

I agree about only using canned routines. SQL direct from client to server is only for DB programmers!

And I don't really trust them, all the time . . .

quote: I use Oracle 8i at work, just storing everything as a blob. They say Oracle promises that 9i, which is 100% java, will outperform any other database by 3 times or else they'll give you a million $$s. Have you heard that yet? Sounds incredible, to me.

incredible, maybe the million would pay for all the licenses we would need
blobs are a wonderful things but they aren't very efficient. You can't index a blob (so selects are slower), and i have a sneaky suspicion that they are stored _like_ filez so that there is a IO weight to each transaction!
I haven't ever played with Oracle, but i guess that any DB can be used if the DBH is well enough defined.
I'm assuming that the server platform will be a flavor of Unix and not an M$ product, dispute the client been windowz only (which is something that i think needs to be looked @)....

quote: Yes, a 'servlet' is just a java 'cgi'. It's a specific type of server-side program designed to be used with a webserver. A 'stand-alone' server, like a 'chat' server, is not a 'servlet'. They're excellent, the little differences are astounding.

Ah, yes my favorite replacement to all my perl code. But the http protocol is a higher level (ISO) than socket comms...

Do you have a database schema you could share with me??

"I'm assuming that the server platform will be a flavor of Unix and not an M$ product"

quote: Originally posted by robin on 10-19-2000 04:23 AM (PS. (on a pedantic point) isn't it so, that, server side java is only called a servlet if it implements the HTTP protocol (i.e. a java cgi)??)

No. Servlets generally allow any service to be implemented, just use
javax.servlet.GenericServlet or
javax.servlet.Servlet instead of javax.servlet.http.HttpServlet.

One question: why are you squabbling over platforms? The biggest advantage of Java is IMHO platform independence. There are even databases that are available for both Windows boxes and Linux boxes (I have Adabas D running with Star Office 5.2 on my machine; it's even free). So, if implemented correctly, client and server shouldn't need to know what machine they're running on (at least in theory).

quote: Originally posted by Bernd Wieboldt on 10-22-2000 03:19 PM No. Servlets generally allow any service to be implemented, just use javax.servlet.GenericServlet or javax.servlet.Servlet instead of javax.servlet.http.HttpServlet.

Yep, but why would anyone want the extra load of implementing stuff their not going to use. One of the main points to servlets is that they can listen/write to the cgi stream (they can be launched, triggured exec, from a URL (well the web server really)), with all the stream handling taken care of. GenericServlet and Servlet are there to allow you to implement your own protocol over the stream.
Its not going to do us any good to use any servlet classes cuss we won't be using a global request server (such as apache).

quote: One question: why are you squabbling over platforms? The biggest advantage of Java is IMHO platform independence. There are even databases that are available for both Windows boxes and Linux boxes (I have Adabas D running with Star Office 5.2 on my machine; it's even free). So, if implemented correctly, client and server shouldn't need to know what machine they're running on (at least in theory).

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.

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).

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.

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.

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)?

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.

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.

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?

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.

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.

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.
}

Just a few quick points on your suggestions:

1. I think your Conflict class and its related classes are unnecessary. Your unitPositions gives all the info that is needed (at least from the client), and I believe Conflict doesn't add anything. Each client won't know for sure where conflicts are, since another player on a different client has freedom to move any of their units to a new position each turn. So IMO conflicts should only be resolved on the server when it has all information.

If that is correct, maybe we should update the page on the web with this info.

Comments:

quote: If that is correct, maybe we should update the page on the web with this info.

I agree. But we should wait about a week to see if anyone has other suggestions first. I also agree pretty much with all of what you said.

Let me see if I can tersely sum up what we're trying to achieve from a gameplay end:

I. Everyone has their own client-side game that has a world model in it. _a. That is what is used for the player interrogating the game on choices.
_b. The player enters their orders using the client (duh!)
_c. Orders are all that is sent to the server at turn end.
_d. Server returns whatever the player needs to know of the game world.

II. The Server has the only Complete and Correct version of the world.
_a. Generated every turn after cranking thru all orders and events

III. The world players have is frequently not 'right' for several reasons.
_a. No godlike knowledge of things down to the last detail
__1. depending on a setting, player knowledge can be very far from correct
_b. Impractical to send complete current world every turn
_c. Player can upgrade world view in client (and so knowledge of world)
__1. thru exploration - more of map is uncovered and updated from server
__2. thru obtaining maps and info from other players
__3. thru 'surveys' of own civ like the domesday book (Richard's idea)
_d. If we want to, this even allows for cases where player only knows what a ruler would know. No instant knowledge of what explorers/TFs far away are doing. FE updates from explorers/TFs you send out could only be implemented when the message/map/explorer returns. This is probably not best for default game, but could be an advanced setting.

Alternately, could we have a seperate 'server' for each model? One computer might control the Ecology model, another could control all of the Technology model calculations, and so on. Tech orders and survey requests are sent to the tech server, ecology information and orders are sent to the ecology server, and so on.

Wouldn't it be better to set up a peer to peer system so a few friend s can have a game?

Of course, ultimately we want both.

By Demo 6 or 7 we might be in a position to clearly separate the user interface from the game engine. Then we might be able to code for multiplayer games.

Cheers

Here is something I could maybe look at! If there is still nobody doing it. I have just finished doing a project using RMI and stuff. I think it is probably easier to have some sort of central server (on one of the users machines). I would need to look at how I could integrate something into the games architecture but it shouldnt be so bad seeing as the game is already multiplayer in the fact that it has the AI players. Just need to be able to replace them with human ones!

Anyway I will have a good look at this thread (and code if I get it) later and then come up with some more ideas.

It'd be Great to get this going for demo 6.