Sorry, kdx7214, but your character in particular has already been chained and padlocked to the server. Only Dr. Tyche has the key -- hidden *somewhere* in his beard! *sage nod*

Cool.

As long as our characters have a Master Lookup table thats Indexed. :) And lets not Drop/Delete row entries until low load times, just set a flag for it to be dropped later. Hate the time it takes to reindex. Of course we can also use Constraints and have multiple Index tables, and just UNION them with the Constrain field(s). Some Database engines will know from the costraint which lookup table it should query for the Characters Info. I'm not sure if the Databse Engine will me MySQL or some other. As long as its not HP's NON-Stop SQL MP/MX/etc...

...and that Lookup table can point to other linked Servers/Databases that have an equal, or close to equal, number of Characters on each for load balancing reasons.

ex:
[img]http://img268.imageshack.us/img268/5742/x85a.png[/img]

So, if we want to add support for even more Characters/Databases, no worries. ;)

Since i'm not sure what all the high level fields will be in the Master Lookup table, i'll just use the players unique Global Handle as the CHECK Constraint and possibly use the 1st 2 or 3 (more or less, will see) characters from the Global Handle to determine which table to Insert all of the player Characters high level info into.
A stored procedure would actually do that, you would just pass in the players Global Handle name.

Example:
exec Characters_AddNew( 'DelightMan', etc... )

.... that SP would look at the Global Handle name 'DelightMan' and take the 1st three characters and insert the high level details into a table named something like 'tblCharacters_DEL', which would have a CHECK Constraint in the CHARS_GLOBAL_HANDLE field, that checks the 1st 3 characters in the Global Hadle string to see that it really starts with 'DEL'.

It stands to reason that on the Character Select Screen, the player will be able to switch between characters allot faster... by keeping high level details of that Global Handles characters in the accessed table thats already in memory of the Database Engine.

If some Master Lookup Tables start getting large (Global Handles names that start with a 'The'), those tables can be split into multiple tables using 4 or more characters in the CHECK Constraint. There would be a Stored Procedures (or user functions) that would actually do that. Get Coding NAOOOWW on that Stored Procedure! ;)
The SP could be run when the loadtime is low, or it can be scheduled, so its automated. (We need to have it automated as much as possible, so maintenance downtime isnt 2 hours, but 10 to 15 minutes)

The SP that would do the nightly / low load times maintenance tasks, would also be responsible for rebuilding any Stored Procedures that used the 'tblCharacters_*' tables.

Example:
exec Characters_GetAll('DelightMan')

Or even better, instead of rebuilding each SP, rebuild the TableView 'tvCharacters' which all the Stored Procedures would use in queries.

'tvCharacters' would have a query that would UNION all the different 'tblCharacters_*' tables. When you do a query like:

Select * from tvCharacters Where CHARS_GLOBAL_HANDLE = UPPER('DelightMan'), the Databse Engine is smart enough to realize that you are actually just quering the table 'tblCharacters_DEL', and not bother reading the other gazzilion other tblCharacters_* tables. ;)

Inserting New Characters should be done through the SP, like Characters_AddNew(), since the Stored Procedure will need to look up the proper table first. The nightly maintenace SP would also change another lookup table which will contain a row for each 'tblCharacters_*' table and it would have fields populated with the CHECK Constraint characters used and other info too.

Or, try Insert Into tvCharacters using an ‘Instead of trigger’. (ref: http://www.codeproject.com/Articles/236425/How-to-insert-data-using-SQL-Views-created-using-m) but i've never used it, so cant say it will work. :/

well, maybe someday. ;)

XMPP, haven used it.
XML based? I always liked JSON more! ;D

Article on How an MMO Works: http://electronics.howstuffworks.com/mmorpg8.htm

What kind of MMO Server will CoT run on? Googling I came across one here: http://www.smartfoxserver.com/
and some White papers on How To do it right: http://docs2x.smartfoxserver.com/Overview/white-papers

Even if CoT wont be reading data from a SQL server for direct TCP/UDP transmissions, i gather it would make more sense to have a central location where you can Update Mass amounts of data in a few query statements instead of traversing any type of Folder structure to update files individually. That sounds horrible.
If a Folder/File structure is what CoT wants, it can be done, but done in a Cached manner prebuilt from the DB.

Ex:
When a Characher's (lets call him Alex) costume, or other data changes, the DB is updated, and a JSON (or XML) representation is generated and Encrypted/Zipped just Once (until the player makes a change again) to a Chache Folder for that particular character (Alex).

When Alex comes across John in the Game World, instead of sending TCP/UDP packets to John from the Database (from a SQL Query), or even from Limited Memory (how much is enough memory?), it does so from the hard disk from the pre-generated details for Alex (which doesnt need to be Encrypted/Compressed yet again). Of course, the Cache Folder would contain things that arent hapening in realtime (Costume,Biography,etc.. things that you would normally use the TCP protocol for). And, Non-realtime Character details doesnt have to take up memory for the span of the instance for that Charcter, the JSON encrypted/compressed character info can be accessed from the Solid State Chache drive almost as fast as if it was already residing in memory and sent right away.

The other player would get Alex'es Character Details and it would stay cached on his local hard drive until the next time when this players comes across Alex. So, as long as the Cache size hasnt grown bigger than... err a Gigabyte on the local players machine (older Character Cached details can be deleted to make room), and the timestamp and the CRC Checksum match, there wont be a need to TCP Alex'es Character details again. Just need to check the CRC Checksum and timestamp once Alex comes into the same Instance (or channel, or shard, or what have you). I know CRC Checksums arent 100% reliable, but it will discurage allot of would be mod'ers.

And use UDP for other things that can change from one second to the next (like players location, Health, Endurance, maybe even powers being used if multiple sends are used with some progression meter of cast time or something to denote progression so other players games can catch up).

Of course, since a UDP packet doesnt have to be received in the same order it was sent, any UDP packets that has a Past progression stamp than the Last one, will be ignored. and the Animation power will start to play using the Last progression stamp point on the other users end. And yes, we can use a Globaly Unique genereated ID for Alexes power when he casts it, which will be included in the UDP Power Cast details, but might be overkill. ;)

Doing this will prevent Lag Jumps you see in some games, where the player's running in front of you, an for a second is right beside you, and then jumps back to where he was, running in front of you again. And yes... i have considered, a sort of Torrent download approach (from others in the same Instance that have the Character Detailes cached), since the Character Details can be checked via CRC and a timestamp which others would get from the Server, but i havent considered it much. Not sure... I'm worried about other players connections, as far as uploads speeds are concerned. If slow, some things about Alex will be there, and not othere aspects.

And, its possible you wont need as many virtual machines, well.. much less. Since i dont know the OS in question and the number of Sockets Available. :)

On some 64bit Linux distros, some say 65k open sockets with 128k rmem and wmem buffers take 8.3GB of RAM. Some say FreeBSD might be able to handle 100K open sockets.

Also came across this, The C10K problem: http://www.kegel.com/c10k.html
I read that some async IO/socket creation calls will freez until it return an open file/connection, but calling it from a separate thread doesnt freez. Sounds like a Thread Pool might come in handy, that return a unused thread, opens the connection and on completion returns the thread back to the Thread Pool for reuse. This always makes me think of how iPhones handle large scrolling lists, reusing the same 3d hardware planes as soon as they scroll out of view and repositioning them at the begining/or end (off screen) for reuse. Even though the dynamic material/texture for that 3d plane cant update so fast, they still show the generic material/texture until the display can catch up for it to redwa the material/texture in that 3d plane (List Item).

Just plop it on a Server like this one: http://www.newegg.com/Product/Product.aspx?Item=N82E16816101676
I dont know servers that well, but others seem to like that one. ;)