Jump to content
  • Advertisement

fingh

Member
  • Content Count

    365
  • Joined

  • Last visited

Community Reputation

142 Neutral

About fingh

  • Rank
    Member
  1. Quote:When you're OK with delaying user response by RTT, that's pretty easy to do. Additionally, there are some things you can do to minimize or eliminate the perception of a delay on the initiating client: - Play a sound that acknowledges the command. This lets the user know that the command was correctly issued, and it distracts from the visible delay. (common in RTS) - Use graduated stop/start for movements such that speed builds up from 0-max over some time frame, like half a second, or even a full second. Vice-versa for stopping. This allows the client to begin the movement before confirmation by the server, but still requires minimal 'pop' or correction if the server replies with an alternate path or disallows the action.
  2. fingh

    help me build the server (hardware)

    Quote:i was assuming that when i called an update statement that the change was made as soon as i called the function Run_Querey("update table ..."). so then you dont think this is guarenteed to happen? Chances are, the DB API itself is using a socket to connect to the DB server. So no, it isn't guaranteed to happen right away, and if there's no concept of 'store and forward' implemented, then it's not guaranteed to happen at all. In best case scenarios, you can reasonably assume the data will update in a timely manner, however please note the keywords "reasonably assume" and "timely" which are variables according to your own code and requirements expectations.
  3. fingh

    help me build the server (hardware)

    Quote:Original post by Anonymous Poster Having worked on a major MMPG... ... make sure you program "solid" multi-threaded code. You can "NOT" do this without at least one SMP machine. This means that your primary developement machine needs to be a dual processor, dual Xeon or Athalon doesn't matter, just be sure it's two honest to god processors. ... Long story short. Program for threads and remote latency using pretty much the worst hardware you can get. Building "big" boxes is actually counter to the idea of building something simple (for 32 players) and then scaling up because it will not "show" the issues with scaling. There are only two MMOs that I know of (having worked with several of the "major" ones myself) that use high-end hardware. For scalability and cost control reasons, using numerous cheap (i.e. 1U single-CPU) servers is the way to go for game state management. For bottleneck processes, you beef up the hardware to meet your scalability requirements. Your edge servers (app gateways, whatever you call it at company XXX) and your DB server(s) will be the first weaknesses exposed in the infrastructure of any MMO. I agree that *IF* you use multithreading, you need to make sure it is "solid". Multithreaded code is typically an order of magnitude more difficult to debug than single threaded, and in a service oriented environment your number one priority has to be to keep the service running - maintainability of hardware and software are the things that will keep you in business. Again, for scalability, consider using discrete processes rather than threading. You can always move a discrete process to another piece o' cheap hardware (IO threads excluded for obvious reasons).
  4. fingh

    MMORPG Servers question

    Quote:Hplus0603When you run these games operationally... Quote:To their credit, these aren't easy problems to solve. On the other hand, they should not be as bad as they in fact are, and with a properly distributed (cluster or other arch such as numa if they have the cash) engine they could be turned from rules to exceptions. "When you run these games operationally" (you aren't alone in this HPlus) you realise that there is more to running an MMO than the specifics of your software. If your software design requires expensive hardware, you might not see 'gold' because you can't afford to a) purchase the servers b) pay the AC bill required to run the servers or c) hire the 24*7 IT support you need for maintaining the servers. In order to develop the "proper" distributed system, it takes time. Again, if you "take the time to do it right", about the time you are halfway finished you start missing payroll. See the trend? The optimum backend design for an MMO is that which meets both the budgetary and technical requirements of the developer. I'm not saying that we should strive for mediocrity, please don't misunderstand the point. As far as elitism, well, better to sound "elitist" than ignorant I guess. I don't come to gamedev to chat with my "customers". I come here to discuss technical issues with a wide mix of technical people, from beginners to pros. In doing so, I'd like to think they are interested in using (or learning) the appropriate terminology rather than regurgitating what the "customers" say. The case in point bears extreme relevance to this forum - a truly clustered system is much more expensive to acquire, maintain, and develop software for than a lan-based "cluster". The software design itself can also be much different between the two. /sarcasm on Since it was mentioned, "Brell Serilis" _IS_ a "server". It refers to a 'worldserver', which *gasp* happens to be the name of an object/module. Additionally, "Brell Serilis" runs as a discrete "worldserver" server process. /sarcasm off
  5. fingh

    Distrabuted MMO Design.

    Quote:Nice CoderYou have a set of servers. The client connects to the geographically closest server, which is not overrun, and which has the lowest ping times. Cross "geographically closest server" off your list of requirements. It doesn't matter unless you specifically want people to play within regional boundaries. Geographical proximity has very limited relevance to ping time. Quote:Nice CoderThese are groups (chains) of servers which have a very small ping time, compared to others (for eg. one would be run by 5 or 6 servers in sydney, melbourne and newcastle, using the same isp From personal experience having worked with commercial MMOs and big-name game services - don't put them on the same ISP, even if they're in different datacenters. Quote:Hplus0603Having played extensively with these kinds of parameters, it's been my experience that 600 ms one-way delay and 5 Hz update rate isn't enough for good interactivity. The acceptability of these parameters is wholly dependent upon genre, entity density, and the availability of advanced synchronization techniques. 600ms is a fairly common peak-time RTT, and 600ms one-way should certainly be managable in bursts. Obviously I would not condone/promote/advance any architecture that inherently imposed these specific parameters, but any viable MMO will need to gracefully handle cases where these parameters occur due to less-than-optimal conditions.
  6. When using traditional network stacks, memory bandwidth through the CPU isn't the only thing going on... Quote:And that server is so cheap these days; you can get one for like $600. servers ARE getting much cheaper. But so is data-center space. You guys are in the Bay IIRC, and that means big bucks (I'm down in OC, same deal here). To answer some of you other concerns: The board was PCI-X, and since we didn't copy data across the PCI bus, reaching 1Gb was not difficult at all from a single machine. We didn't market our solution for dynamic environments, only for static or streamed content that can be precached. Hence the FilePlanet or patch server illustration rather than something more game-centric. *edit* Quote:And did it use a standard sockets API for the application programmer, or was it a vendor-proprietary interface? I have a very hard time believing that offload hardware makes sense these days for things other than routers. Price was high, indeed. We provided a proprietary socket interface that we used internally to port very specific software (one more part of our markup). They were working on a BSD interface just before I left. There are lots of uses for offload (again, video/audio streaming comes to mind). The per-player networking requirements on the games I've worked on have never been the limiting factor to how many players a machine can handle. But since TOE solutions will soon be standard for NICs, just sit back and enjoy. Intel already ships a GigE TOE standard on many of their server MBs.
  7. My previous company (Xiran, a division of SimpleTech) developed a zero-copy TOE implementation that pushed wire speed on GigE at 0% system CPU utilization. The key is to offload from the PCI bus so it isn't the bottleneck. In dynamic environments (game server), this isn't so useful, but consider something like FilePlanet or a MMO Patch server where you can cache the static files in advance and then push it out with all the protocol work done in hardware. That's what we did for Real Networks, and it worked quite well for data streaming. I hear it also works extremely well as an iSCSI target/initiator. TOE will be useful in any heavily-networked environment, as it relieves system CPU from trivial calculations such as checksumming and windowing etc. You might not benefit from increased network throughput (because of aforementioned bandwidth bottlenecks), but with the same throughput, you might end up with spare cycles for AI, database transactions etc. Not all fast games use UDP. World of Warcraft uses TCP exclusively , as does Warcraft3. Additionally, there are some hardware components that simply don't work well with UDP (ServerIron and some other load balancers etc, and some NATs).
  8. fingh

    Another song by me=)

    Nice work, I checked out the other stuff on your site as well. Keep at it.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!