[Bobboau]

was wondering, if there could be some way to set up a multi-player system  that could replace the old PXO, I'm less concernd with stat traking than all the other things like the chat rooms and servers and stuff like that

[LtNarol]

not hard to do, just need a programmer, a few very high power computers, and a high speed internet service....SHRIKE!  

[##UnknownPlayer##]

Simplest way as I see it would be to use XML stored on a server somewhere, and all servers starting up simply post a few details to it. The page serves as the in-game browser, and since the FS2/3 community is relatively small we should be fine.

[Inquisitor]

Yes, it is possible. Max Gaming has already warmed to hosting something like this, at least for a test.

Start with some generic master server and chat server, and go from there, would be my inclination. Build or buy a good IRC service (unrealircd, for instance, freeware IRC server) and build a simple master server interface in parallel with that (or steal one, ala one of the half life open source master servers).

once you have the system working like you want it working, then you implement an IRC client in the game But get a system working first. Till then, you launch the game from whatever the chat client is, with whatever command line params it needs to connect to whatever IP address.

That's how I would do it.

Someone, not too long ago, wrote a replacement master server for Descent 3. But they then disappeared and never (to my knowledge) released the source. It was java based, which is good, because it doesn't really matter what your service provider ultimately is, it had redundancy built into it (it was multinode), and it was pretty stable. If someone could find that guy (I have looked, with no success) and better yet, that code, we're halfway there.

[Kazan]

i'd like to see a real, dedicated server app using mySQL

[Inquisitor]

that's a real possibility.

I am still not convinced mySQL scales, but with the number of people likely to be using this, mySQL is an excellent choice.

I looked at some mySQL possibilities, but no current code exists that I could get at. Anyone feel up to the challenge?

[Kazan]

i know SQL and the mySQL++ interface [the latter being their cross-platform library for connecting to a mySQL server and using it in C++]

[Inquisitor]

Yes, I know what the interface is

I have it working currently in TQ, exposing the SQL calls from the console/script engine to read and write data.

I like mySQL, it's a great concept

[Kazan]

with mySQL++ the C++ API handles connection, and data retrieval - you still send normal SQL queries

[penguin]

I will play my tired old song again...

Whatever we choose should be as portable as possible, especially since this is a back-end type of thing, and could just as likely be running on Linux with MySQL, on Solaris with Oracle, or on IIS with MS-SQL (wince), or in a server farm with all of the above...

Unfortunately, doing it in C is probably the least portable way to do this, since any db access API are inherently non-portable across databases.

I suppose it depends on the environment that we will initially have hosting it, but I would lean more towards something like Java Servlets/JSP... but I'm sure this is a religious issue for many of you  It's portable and scales well is my main point here.

Inquisitor: I don't know how big a deal the scalability of the database is... in fact there would likely be only a few tables (players w/ stats is the only one I can think of...), and would only need to be updated when a game is completed.  And until we have 2,000 simultaneous games, it probably isn't a problem as you pointed out...

I'm not nuts about MySQL, but the price is right and it's very portable.

[penguin]

What are the specs for this?  I don't play multiplayer much, but here's what I can think of, at a very high level:

Player management:

• registration
• authentication
• stats/ranking
• admin options: reset password, ban, etc.

Game/session management:

• coordinate current game servers
• track game status (starting, in play, etc.)
• record stats at game end

Other stuff

• channel/lobby managment
• chat

And although the stats inflating problem (cheating) will be tough to beat, we could use some sort of public-key enryption (like RSA) for stats updating... that way we could make the server source open, but still have a degree of security by not releasing the private keys of the stats servers...

Any of you SW types want to add to this?

[Inquisitor]

Start simple

We'll get to stats, etc, but a master server and chat server is the place to start, get basic join game functionality working from a standalone external client (ala gamespy or kali) then we atart architechting a database driven stats solution

Once you have a master server and a chat server working, then we can start fiddling with the FS2 source to add a chat client and join game stuff. I just got my new laptop setup, and have the megamek chat/master server source. I have to look at it anyway, might as well make it pull double duty. One thing I want to add to this JDBC calls to track things in a db, so, I'll know more later in the week.

mySQL may still be a good solution for a master server, have it write the "what server is online" stuff to the db. I'm not worried about mySQL scalability here, just because of the low traffic (I don't think it would break even at 2000 ).

That's my continued nickel

[penguin]

Would anyone get upset if I took out IPX support?  Does anyone use this at all anymore -- or did they ever?  It strikes me as a holdover from the Descent II days...

I am trying to tidy up the network code and it would be much cleaner without all this dual-protocol stuff around.

(I suppose we could plan for the future and put IPv6 hooks in there, but I think this might be a waste of time; IPv4 is gonna be around for a while...)

I will post a state diagram when I understand it better

[Inquisitor]

Taking out IPX might break Kali-support. Not sure how big a deal this is, but it IS the only decent psudo replacement at the moment for PXO.

[penguin]

'nuff said... it stays in.

[Blue Lion]

heh, Maybe we can make a new SW to go with it :wink:

[penguin]

Originally posted by Blue Lion
heh, Maybe we can make a new SW to go with it :wink:

Yep.

Like to get all the good stuff (and none of the bad) that PXO does.  SW is definitely on The List™.

[WMCoolmon]

Isn't TCP/IP support already in there? (For direct connections)

Edit: Doh, sorry, forgot what Kali was

[penguin]

OK, I did a packet capture of much of the PXO stuff to see what's going on...

So far so good, it's not too complicated, and 75% of it is connectionless (UDP).  Interesting (or maybe not) that all of the chat stuff is vanilla IRC -- in fact, the IRC server chat.pxo.net is running Linux

There are 4 servers:

www.pxo.net -- (TCP/HTTP) get banners and code versions (probably not needed)
chat.pxo.net -- (TCP/IRC) chat server; channels are used for "game server"
ut.pxo.net -- (UDP) login validation
gt.pxo.net -- (UDP) game server - lists active games
[/list]
BTW I'm not really trying to reverse-engineer it, just trying to understand it.   In other words, what we build will most likely not be compatible with the commercially released fs2.exe

[Kazan]

i say stick to the vanilla IRC