Advertisement

DPlay for MMOG - why so bad?

Started by November 24, 2003 02:01 PM
24 comments, last by Synth0id 21 years, 2 months ago
quote:
Original post by BrownBean
quote:
Original post by Imperil
mySQL does NOT have any stored procedures, which is why it is rendered helpless when compared to MS SQL and Oracle.




MySQL version 4 and up does have stored procedure support:
http://www.mysql.com/products/mysql/index.html


Correct me if I'm wrong but doesn't DirectPlay have more overhead than UDP or TCP.



Check that link again and read near the bottom where it talks about stored procedures:

"Support for stored procedures and triggers will be introduced in version 5.0." <-- right from your link.

I remember back with version 3.0 they said "Support for stored procedures and triggers will be introduced in version 4.0."

They have said for about 5 years now that they will be adding it.. but as of yet they have not =]


EDIT: Sorry I just realized that you already found this out. Although the fact is that the mySQL team has stated they will be having stored procedures for YEARS now and have never pulled it off.

I would absolutely LOVE if they could do it.. but it will still be too late when they do. Microsoft SQL Yukon you are able to code stored procedures using native managed .NET languages (C#, mC++, etc) and have them compile. Hopefully mySQL will at least have the old-school stored procedures by the time Yukon launches.. otherwise they will be light years behind =]

[edited by - Imperil on November 26, 2003 2:11:42 PM]
I believe There uses MySQL for persistent storage, and a custom database for real-time on-line uses. They also use UDP for position/simulation networking, and TCP for chat/transaction networking.

I believe it''s important to not stare yourself blind at the ability to make something "reliable" on top of UDP. This will usually run into the same penalties that you get for reliable networking using TCP. Instead, I think it''s important to design your protocols to cope with loss, not by re-sending the same old data, but by using the freshest data available, and treating incoming packets as refreshes on the available database of simulation state.

Then, most of the encapsulation on top of UDP becomes moot; instead your system is such that it will work on any amount of connection loss; it''ll just give the user a smoother behavior on links with less loss, which I think is a desirable characteristic.
enum Bool { True, False, FileNotFound };
Advertisement
quote:
The only limitation I know of is the ''WaitForSingleObject()'' call which cannot monitor more than 64 handles. There are other mechanisms for scaling up a server and DPlay uses IOCP instead so this limitation is nul & void. Read chapter 6 of "Network Programming for Microsoft WIndows" by MS Press for the details.


The non advanced-server versions of windows have limitations on the amount of TCP connections and the number of processors you can use in the system.



Looking for a serious game project?
www.xgameproject.com

Looking for a serious game project?
www.xgameproject.com
@MaxPayne

DPlay uses reliable UDP and so that TCP limitation does not apply.

synth0id

There is no point in doing anything at all, you'll die pretty soon anyway.
> The non advanced-server versions of windows have
> limitations on the amount of TCP connections and
> the number of processors you can use in the system.

You wouldn''t want to host a full-fledged MMORPG on Windows 98/Me would you? Windows NT4 and up is necessary for best performance (Professional or Server flavor).

-cb
Most of the posts in this topic are not even on the original topic of DPlay =P.


My best suggestion is to write a small test app that would connect to your test server many times and send the amount of data you think you will send during the game. See if it will hold up.

This topic is closed to new replies.

Advertisement