Is IP Multicasting used often in multiplayer gaming networks? I recently read the book "C# Network Programming by Richard Blum" I read many technical books and found this one excellent. http://www.amazon.com/exec/obidos/tg/detail/-/0782141765/ref=wl_it_dp/103-6283625-6500668?%5Fencoding=UTF8&coliid=I1NI9J0YKC265I&v=glance&colid=KLQ6H9BHYG9L I want to create a very simple "for learning purposes" C# network library. I want to code the most typical approach. So far, I am thinking the typical game approach is: 1. UDP. Should I consider IP Multicasting? 2. Async. Should I use .NET threads or the async methods of the socket class? or combination? Does this sound like the typical approach? I have created a very simple puzzle game in C# using Managed DX. I want to code for a max of 10 players to be able to join a multiplayer game. I very much look forward to any ideas/feedback/advice. Sincerely, Dan H.

Don't bother with multicasting, it won't work over the internet anyway.
It's mostly useful for things like video conferences on local (corporate) networks.

Quote:

Original post by Ghhetto1. UDP. Should I consider IP Multicasting? 2. Async. Should I use .NET threads or the async methods of the socket class? or combination? Does this sound like the typical approach?

1. Most games use UDP but it's not strictly necessary, especially not for learning purposes.
2. Async is good enough for most games. And a lot easier than dealing with threads.

Majority of ISP's do not enable multicasting on their routers, so yeah its pointless.

UDP is great for games that are "real time" and demand low latency. If you care about these things, and have a state model that allows for missed deliveries, then UDP is lower overhead, lower latency, and lower jitter. For a puzzle game, TCP is probably a much better choice, though -- much easier to work with, and puzzles don't need those features.

Threads usually get in the way more than they help, as most machines are memory bound these days, most users don't have quad CPUs laying around, and HyperThreaded CPUs just starve for cache that much faster. Not to mention thread synchronization is expensive. Async is the way to go if you care about these things -- else use whatever you're most comfortable with.

When it comes to multicast, here's why it just won't ever work:

1. You form multicast group with another host.
2. You chat just fine.
3. Now a third person wants to join, somewhere on the Internet.
4. Oops! ALL ROUTERS ON THE INTERNET need to know about your multicast group, in order for some new random person to join.

Single-source multicast ("unicast" routed over a WAN) has some potential, because it saves bandwidth on the backbones, and works for things like web video broadcasts, but it's un-clear that it would save enough to be worth the investment -- and it's no use for interactive games, anyway.

Thanks guys for all the replies. I feel alot more confident with my direction now. What did people do before the internet?

Sincerely,
Dan

Read books, pretty much.

Oh, and met in person.