Multiplayer Coding/Issues

[Osiris]

thanks for telling about workshop 3.0, and sorry Mark about saying those things, oops

Well, heres a new plan for everyone, I am going to make a good chating program that has the same design as the clashnet design that we can use for meetings It should take nearly as long, by the end of this month I should have it done, no more ICQ

[rentgen]

Guys,

I've read through this thread and i still don't get it. WHY do you prefer peer2peer to client/server?
How is combat outcome is going to be determined in your model? Specifically, on which machine? Having rmi server running on each machine is a HUGE overhead and RMI is SLOW.

Concerning server crashes -- first, it is possible to write a server that WON'T crush, and even if it does crush it is fairly easy to implement RECOVERY protocol. Do we want Clash to be a GOOD game or just a bunch of code put together? What if one of the players in peer2peer crashes -- not so fun for him/her, and having a recoverable server he can just restart and get the data.

Well, these are just few ideas. If i'm getting something wrong, please enlighten me

Osiris, about the compiler -- why not use JDK?

Regards,
Anton.

[Lord God Jinnai]

bump

[Osiris]

First off.. I am back!!
wow, back from the underworld parse..
concerning making a chat program, well,
I can make the networking for it.. it would be nice if I can work with a GUI person for that part.. wouldn't be that hard.

Second off.. concerning saying that having a client/server model is more reliable and faster.. well to put it bluntly.. not in my lifetime..
Starcraft has one of the best Multiplayer designs I have EVER seen, and it has a peer to peer model. and it would be a LOT easier to make a recovery protocol with a peer to peer, now yes for each computer it takes a bit more processing, BUT it takes a lot less on the server, because there really isn't one, basically its not really peer to peer, its server to server, and every machine is a server(except when you are setting up the game) but when you launch the game then every host becomes a server and the person that started the game no longer matters.

[robin]

quote: Second off.. concerning saying that having a client/server model is more reliable and faster.. well to put it bluntly.. not in my lifetime..

What?? Cuss you've never had more than two clients??

quote: Starcraft has one of the best Multiplayer designs I have EVER seen, and it has a peer to peer model.

& a v.heavy client comms setup. It maybe fast, but it rips the guts out of your system!

quote: and it would be a LOT easier to make a recovery protocol with a peer to peer, now yes for each computer it takes a bit more processing, BUT it takes a lot less on the server, because there really isn't one,

..easier recovery system - WHAT, THIS JUST ISN'T TRUE!
Peer to peer recovery MUST be harder (than a Server/Client one), since the server (in the client/server setup) knows nothing ~ the client, thus won't care if connection is lost (cuss it was never static), where as, a peer to peer network will 'see' the loss of a client and this must be handled (to avoid errors when you try to send/recive packets from it)

quote: basically its not really peer to peer, its server to server, and every machine is a server(except when you are setting up the game) but when you launch the game then every host becomes a server and the person that started the game no longer matters.

You are _never_ going to get a way without a server, peer to peer like this with high volumes of traffic just won't work! Each client would need to store all other clients addresses and keeps comms open (even if you reinvoke), then if you thread each comm agent, wow thats gona kill most OS's for even the smallest # of clients!
Peer to Peer is better with a v.small set of clients. Server to client is a MUST FOR ALL SERIOUS networked relationships.

AND (on a unrelated post)....

Object _can_ be resolved even if you don't know their type @ design time (using Class.forName etc)!

[F_Smith]

For what it's worth, I absolutely favor a 'client/server' approach -- or, more accurately, I favor a 3-tiered approach, with the game engine running on a server, the game's Interface running on the client, and a 'middle-tier' server that interfaces between the two (which in a perfect world would be on a seperate machine/group of machines).

This is how the game is currently planned. A 'database' server for the game engine code, a servlet-based middle tier running on it's own server (or many servers, for balancing the load, if/when traffic becomes heavy). And an 'applet' front-end.

The applet and servlet will communicate thru a socket.

Does this sound reasonable? Any suggestions/corrections?

[Mark_Everson]

robin:

An official welcome to the project .

I'm really glad you brought this thread back to life!

I think getting MP up fast is very important, because that way we can defer the AI till later and still really test out the game elements. So its great this is where you want to work, very timely.

All:

On the specifics... It looks like we need something thats scalable up to lots of players if F_Smith is to have his mega-game vision which does sound fun as an alternative. So that says client/server to me. But we need to make it so somebody's PC can be the server for a small game. So long as that can be achieved I'll be happy, and accept whatever the pros say.

Another issue to keep in mind, is with the complicated models there will be a lot of BW needed to send the info back and forth. For MP we may eventually need to cut down the model detail, at least until everyone has a hi-BW connection. F_Smith is convinced its not a problem (I hope I'm characterizing this correctly) while I'm not so sure about that. Anyway, for background info, I'd ideally like the turns to take max 10s to execute in 'streaming' mode, including all the communication that will go on. So all the info that needs to be there for each turn needs to take something like 2-3 sec Max. Thoughts on this?

One more thing. I would Really like to use the clients, at least those with enough muscle, to run AI processes also. My AI concept allows parallel processing, and the more computational power we can give the AI, the better it will be.

[This message has been edited by Mark_Everson (edited October 18, 2000).]

[Richard Bruns]

Obviously I don't know about this programming aspect, but I do know about how the models interact with each other so I thought I'd throw out an idea:

If we do them right, the models will be "black boxes" that crunch numbers internally and then send a smaller amount to info to the other models. Could we fix things so that each machine is responsible for number-crunching a particular model? FE one computer could run the ecology and disasters model, another could run all the technology models, and so on. That way, the CPU and memory load is split up and less data has to be transmitted. The computers only need to share the data that has a direct effect on other models.

I'd also like to welcome robin. We need all the technical expertise we can get.

[robin]

quote: Originally posted by F_Smith on 10-18-2000 11:42 AM This is how the game is currently planned. A 'database' server for the game engine code, a servlet-based middle tier running on it's own server (or many servers, for balancing the load, if/when traffic becomes heavy). And an 'applet' front-end.

Yea, although the databases server initially doesn't have to be on a different box. The database to servlet/server relationship is no problems as most DBH's can easily handle changes in db host (and port for that matter)! I would suggest Mysql as its free, well supported (i have a good Mysql Java dbh (database handle) if anyone needs one!) and will run on most platforms (even windows?).
Its such a joy to find a project working on java clients, @ last a chance to ditch those expensive (costing time) protocol routines, and get down to just parsing objects

A (quick) note ~ client/server security:
The golden rule, even if you aren't worried ~ security, never, never let the client send sql statements to the server! A better way maybe to _loosely_ model the RMI system, basically only allow clients to call predefined functions.

You can setup an SSL (Secure Socket Layer) and encrypt each packet, but the dividend is performance, mostly on the server side. A less costly approach is to sign the clients, so that the server can identify them and allow packets. But this does mean that potentially someone could see the content of each packet (so no sending credit card info etc.).

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

[robin]

quote: Originally posted by Richard Bruns on 10-18-2000 09:50 PM If we do them right, the models will be "black boxes" that crunch numbers internally and then send a smaller amount to info to the other models. Could we fix things so that each machine is responsible for number-crunching a particular model?

A good idea but a v.complex one to get right. Distributed (meta) processing only really pays dividends if you have a _huge_ amount of data to process (such as cracking an RSA key). Usually when a server becomes v.loaded you look to load balance the heavy things (databases etc), but you wouldn't expect to move server functions or processes, unless they are implemented as cron jobs (which aren't very stable). Functionally, its always good to separate the clients transaction processes (client comms) from any other database processes, usually its done via threads - and a distributed server model is maybe too complex to get bogged down with now, but when all the processes are defined it could be looked @ again (since we could allways just re-thread on another box (all with a common db server))??

[F_Smith]

Mark:

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

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.

[robin]

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


[This message has been edited by robin (edited October 20, 2000).]

[Mark_Everson]

Hey Robin:

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

Woah there! I hope I've misunderstood you... Perhaps for F_Smiths huge dream games your quoted assumption will be true, but for pickup games the server Needs IMO to be able to be a MS box. Thats what almost the whole world has! I'll wait for further confirmation/denial of this before I put my foot in it further .

[Bernd Wieboldt]

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

How far is the multiplayer model at this point? I'm in since yesterday and interested in mp programming (resume sent). Is it ready for implementation?

[robin]

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

Yea, but its over development platform i'm squabbling ~ (not that everyone needs to use the same OS through).