Rob Loach to give you an idea of how much bandwidth krez is talking about, suppose a game is running at 16-bit colour, 800x600 resolution, 30 frames per second. That's 2*800*600 = 960 kilobytes per frame, multiplied by 30 frames/sec = ~28.8 megabytes/sec. Most internet connections support only a few hundred kilobytes/second, even a typical lan is 100 mb/sec under ideal conditions (in reality you're not going to get close to that on average). And that's just graphics, you also need to transmit the sound data alongside it.

Oh, and there's nothing special about C# that allows you to do that. Any language can support client/server architectures.

Edit: Just so there's no confusion, a typical lan is 100 megaBITS/sec not bytes, which is 12.5 megatbytes/sec.

[edited by - Dobbs on March 24, 2003 4:50:58 PM]

"I haven''t experimented with C# all that much yet but from what I''ve heard/read, you can run a have clients run programs FROM a server, have the server perform calculations, and have the clients SEE the results."

C# is a standart language much like C++.
I guess you´re talking about .Net?

Hmm, that is distributed computing. Try to search google for web services, COM/COM+, Corba.

Distributed computing in .Net is accomplished with XML.

Even before RPC techniques, this was always the basic idea when you are implementing a protocol for a client/server system; RPC just adds another layer of abstraction.

However letting the server do everything is not that sensible, like it was mentioned above, the bandwidth would be too high.

A bigger issue, is that it is not too efficient. If the server had to do everything like rendering, they would have to be super computers, while the clients are sitting at home with 2ghz pc''s and not even using their potential. It would be completly un-sensible to implement a system like this, at this point in time.

Imagine if the server supported like 200 clients, that means the server computer would have to have the power of 200 client pc''s with 200 graphics cards etc: not possible.

Back to your original post - you said C# can have clients run programs from a server and the client just displays the results. That''s not entirely accurate, and it''s nothing new, programs/languages have been using client/server architectures for years. If you care, here''s a brief explanation of what it really is you''re talking about:

Companies wanted to be able to create servers that provide a service that programs on other computers can request remotely - for instance wouldn''t it be nice if you could write a program that runs on your computer and searches Google? Google provides the service on the server-side, you make the client and provide a nice interface/client program. It then made sense to come up with standard protocols and formats for transmitting requests like "Give me the first 5 search results for ''independent game development.''" The industry settled on using XML as the format and HTTP as the protocol, and dubbed the whole system ''Web Services.'' Microsoft is making a platform for providing Web Services called .NET, and is providing languages that support that platform - C# is one of them, others are VB.NET, ASP.NET, C++.NET, and possibly some I''m forgetting.

So really what you mean is "C# provides an easy way to create a client that requests and displays the results of a Web Service provided by some server."