I heard them say the same thing at a conference. Poor people.

We tried running some of our servers on Win2k Server. Didn''t work out very well. Cluster management was harder, and there were more mysterious OS bugs that got in our way -- we had mysterious OS bugs on Linux, too, but there we could use the source!

Another question is:
#10 How to make write operations non-blocking properly, without wasting CPU resources?

What i mean is:

The basic loop for handling read events pending to be handled on a socket (or an array of sockets) looks like this:

while (should_execute)
{
poll_sockets();
if (got_data_to_be_received) receive_data();
if (got_incoming_connections) process_connection_requests();
}

select(), poll() and kqueue() behave the similar way when monitoring the sockets for readability, but what with writing?

When watching the sockets for writeability, the mentioned functions usually return immediately, because inner socket buffers only become full in rare cases... Usually there's always some inner buffer space available, so running this loop:

while (should_execute)
{
poll_socket_for_readability_and_writeability();
if (got_data_to_be_received) receive_data();
if (got_incoming_connections) process_connection_requests();
if (can_send_data && got_data_to_be_sent) send_data();
}

will result in 100% CPU load, because the polling function returns immediately (not always, but in most cases)...

We could add some code to block the networking thread (artificially pause it), for example:

while (should_execute)
{
poll_for_readability_and_writeability_with_zero_timeout(); // this will return immediately
if (got_data_to_be_received) receive_data();
if (got_incoming_connections) process_connection_requests();
if (can_send_data && got_data_to_be_sent) send_data();
sleep_for_some_amount_of_time();
}

but suspending the execution of the thread in such a manner is a bad idea, i suppose, because it damages scalability when server is under high load...

So... how do i perform non-blocking write operations properly?

[edited by - roookie on February 2, 2004 10:50:00 AM]

As the original poster already said, on Windows NT/2000/XP you would use IOCP, I/O completion ports. That''s the fastest and most efficient system for handling 1000''s of connections. I don''t think there is a similar alternative for UNIX.

I'm aiming on UNIX, and if i wanted to make it under Windows, the question doesn't concern the OS... The question is how to set up proper non-blocking writing when using on of the polling schemes...

[edited by - roookie on February 3, 2004 7:29:12 AM]

quote:

---

No trust me, I am 100% positive on that one. Their full infrastructure runs on a Windows platform, I know this for a fact. =]

---

Sorry, you can't possibly know this for a fact because it isn't true.

edit: Let me qualify this a bit further - most of the infrastructure processes CAN run on NT, but they are not run on NT for production purposes. The zone servers run on NT. Session, billing, and (some of the ones that I designed and/or coded) run on linux/solaris.

[edited by - fingh on February 3, 2004 3:01:09 PM]

I thought it was scary when I saw the post about Windows.
Windows are the source of all evil. Recently couldn''t access some ip numbers from work, and our network admin said that our request was going out but reply wasn''t comming back.
After a week of that, he found out that we needed to reboot our Win2000 box (where firewall is installed).
And those damn IP numbers worked fine before, then just suddently stopped.

Just to add a little foddar to the debate on windows /nix servers I''ll throw in my opinions.

Unix is hands down "potentially" a far more stable server. this is due to the afore stated fact that you can disect everything down to source and make it work for your needs. There is zero question that unix makes a great server. the down side to unix is that it draws on a much smaller, more expensive and less available pool of support people than windows. Hey I hate MS as much as the next guy but lets face it you can get all kinds of add in software for windows servers that you would have to code from scratch in unix.

As far as using windows or unix for your game servers, go with what you can support. If the extent of your project is to run an 8 player quake type server for a few buddies and you are a unix geek, knock yourself out. If, however, you are working on an ambitious project requiring servers that may eventually have to be farmed out keep in mind the cost for you to support a unix server environment is substantially more than a windows environment and it also limits your potential bandwidth providers. (assuming your server farm will be housed at a broadband headend.) Windows servers allow a much broader spectrum of hardware compatability (out of the box with out re-writing drivers etc.) and a lot more network management tools, again plug and play out of the box. Yes anything that can be done on windows could be done better in unix but in a commercial production environment you need fast, costeffective and availability of parts. Windows offers that.

Ok, please bear with me I am not an MS fanboi. I hate MS for what the do to O/S''s but through my hatred I have managed to better myself by disecting the windows O/Ss to pieces to get the most out of my PC.

First off, lets clear up some misconceptions. If you run a stock install on a win2k or win2k3 server you are insane. May as well go hang yourself A win2k server demands severe customization on install, striping every service known to man from it. Strip it right down to nothing. Manually tinker with the registry to tweak things like memory paging, file logging, caching etc and you can get an approximately 80% performance boost on your hardware. Run a striped drive array to get an approx 25% boost in data access performance with a caching controller and 2 gigs of ram and you are set. I am not joking around here btw, I do configure probably 1-2 of these large scale servers a month. They dont cost 10k anymore and they do run smokin fast. I could build a server like I described above single processor for under 2k canadian dollars. dual processors for under 3k.

I digress. Bottom line is, design for the platform your business plan can support. If you are a unix geek and your the only person that will have to support your servers then go unix. If you have to plan for other people to support your servers keep the above things in mind.

Cheers

Mark

Aakrana: The Forgotten Lands
If you have C++ experience and wish to
assist in the alpha development of our network
transport using very easy middleware, please contact me.

quote:

---

Yes anything that can be done on windows could be done better in unix but in a commercial production environment you need fast, costeffective and availability of parts. Windows offers that.

---

Thanks for not offering the typical overly-biased dogma that we usually see on GD. I also have had to put aside my better sense of judgement in order to 'accept' Windows as a necessity to some extent. That said, I'm curious if you realise that commercial (and non) flavors of Unix have been the backbone of the Internet and corporate networking for years. Windows is still relatively new to serving enterprise environments, and is still a fledgeling in most of it's up-and-coming-monopoly markets (database comes to mind). Note the term 'relative' lest I be flamed by the less attentive readers.

The simple fact is that you don't buy a bunch of rack mount servers with the intent to run *insert any OS* without validating the platform first. Once you get a system that works, you clone it. You ghost the drives (and the tuned kernel you are using). You buy the hardware in quantity (at discount). If you are planning to run any kind of largescale game network and don't have the staff to properly maintain the network, you're kidding yourself.

quote:

---

As the original poster already said, on Windows NT/2000/XP you would use IOCP, I/O completion ports. That's the fastest and most efficient system for handling 1000's of connections. I don't think there is a similar alternative for UNIX.

---

On Windows, the most efficient system of multiplexing 1000's of players is to use a single UDP socket with a moderately large recieve buffer. If you are using TCP, you might consider IOCP, but you might be adding unnecessary complexity to your architecture. IOCP isn't the catch all of network IO. Also, Unix systems can use the Posix aio* (asynchronous IO) functions, but OS support is still somewhat limited.

I'd question any architecture that required a single system to manage many thousands of active, persistent connections (regardless of protocol). If you are designing in this mode, I'd suggest you take a look at the high price of high-end server hardware. By distributing your code (and your player load) over many processes (and subsequently many low end servers) you can increase the fault-tolerance of your system (if a single isolated process or system goes down, only a few people are affected). You can also simplify your processes by having each one accomplish simpler tasks rather than one giant server process that 'does it all' and requires $100k of proprietary hardware. This approach isn't just for 'zone'-based partitioning, it works with seamless worlds as well.

[edited by - fingh on February 4, 2004 6:59:28 PM]

As I said before: We tried Windows. It had problems. We ditched it.

Sure, our operations people are paid decent salaries. They''re worth it, because they''re GOOD.

We''re leasing some number of racks at one of the top-tier trunk co-los. We buy 1U rack machines from one of the few trusted, local screwdriver shops. When a machine goes bad, we decommission it and send it back, and we don''t ever see it back. We also designed our software to allow for almost-live fail-over to generic systems all running the same software install. ("almost-live" means about 30 second migration; less if the host isn''t too loaded)

When we grow, we send a person or two into the area with a power screwdriver and 50 more boxes. We even have a special parka for doing this, as that room is freezing! We''ve done this several times. We have netboot self-install auto-configure Linux set up in a way that makes it much easier to go from scratch than you could do with Windows.

Linux treats us right.

quote:

---

We''ve done this several times. We have netboot self-install auto-configure Linux set up in a way that makes it much easier to go from scratch than you could do with Windows.

---

yeah, this is common practice for data centers and vendors such as Dell(because it''s the ''right'' way to do it). Incidentally you can do the same with Windows as needed. My servers run on both windows and linux because having a solid portable framework was one of our design goals. In production we run servers on 100% linux.