 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Advanced WinSock Multiplayer Game Programming: Multicasting |
|
 |
Anonymous Poster |
|||
 Posted - 11/9/2001 4:42:27 AM |
||||
| Hey Author , Nice Articel, I think this is really cool ..... This can speed up games to a new level.... |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 11/9/2001 7:45:42 AM |
||||
Thanks  Hey, I sent an updated article to replace this one.. this is the old version. Grr.. *sends email to Dave*. - Denis "Voxel" Lukianov |
||||
|
||||
|
Voxelsoft Member since: 12/17/2000 From: York, UK |
|||
 Posted - 11/9/2001 12:51:49 PM |
||||
| Ok, cool, up now |
||||
|
||||
|
henryx Member since: 4/29/2001 From: Dundee, UK |
|||
 Posted - 11/9/2001 4:04:10 PM |
||||
| Yep, I liked the article too but I have a couple of questions for you. 1. Can any IP be selected (within the range that you specify) for the multicast group and how is this regulated. What if I choose an IP for my multicast group which is already being used by another group. I'm not sure how this works. 2. When a message is sent to a multicast group where is the message regenerated so that it can be sent to all the group members. How do we know that the message has been sent to all the group members and is it possible for an individual member to get the same message a number of times. I'm not sure about this bit either. Thanks for the article henry |
||||
|
||||
|
Voxelsoft Member since: 12/17/2000 From: York, UK |
|||
 Posted - 11/10/2001 4:28:36 AM |
||||
| Hey henryx, Okies... 1. Yes. How it is regulated depends on the network. If you get "success" returned, it worked otherwise, it didn't.If you use an ip already taken by another group you will simply join the other group and send/receive to/from that group just like the other application. This is why your application should use a specific and unique port. Failing that, make sure your packets have some sort of recognition header that will filter foreign packets in your own code by their header. The problem above can occur with unicast as well so use unique ports and make recognisable packet headers for your apps.2. The packet is generated at the sending host. The packet is replicates on the network infrastructure - good old routers and switches. The packet should be delivered to all the group members (including the sender if it has joined), but just like any unicast udp packet it is not guaranteed to be delivered by the service. Individual members should not get the same packet a number of times unless they join the multicast group on different interfaces (eg if your pc had multiple ip's). Hope this helps, - Denis |
||||
|
||||
|
henryx Member since: 4/29/2001 From: Dundee, UK |
|||
 Posted - 11/10/2001 10:58:39 AM |
||||
| Yep, Thanks voxelsoft, that helps me understand what is going on with multicasting. One further question though - I assume that the multicasting IP that I choose for my group is not related to the IP address of my own host PC. So does that mean that my host PC is looking for communications over the network both on it's own local IP and on the Multicast IP. Thanks again, henry |
||||
|
||||
|
phueppl1 Member since: 7/11/2000 From: Alkoven, Austria |
|||
|
Posted - 11/10/2001 11:58:49 AM |
||||
| Nice one! I remember a thread I once started about 3/4 of a year ago... I got a response from somebody that meant I was completly dumb to assume something like that would work.. and now this article =) thx! cya, Phil Visit Rarebyte! and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states  ) |
||||
|
||||
|
Voxelsoft Member since: 12/17/2000 From: York, UK |
|||
|
Posted - 11/11/2001 5:58:44 AM |
||||
| henryx, "IP that I choose for my group is not related to the IP address of my own host PC" - True "So does that mean that my host PC is looking for communications over the network both on it's own local IP and on the Multicast IP" The Multicast IP exists on the network infrastructure, not on your PC. So when you send to a multicast IP you are sending from your PC to the network infrastructure and when you are receiving you are receiving from a group, you are receiving from the network infrastructure and not the sender directly.- Denis |
||||
|
||||
|
henryx Member since: 4/29/2001 From: Dundee, UK |
|||
|
Posted - 11/11/2001 7:49:58 AM |
||||
| Ok thanks Voxelsoft, think I've got the idea now. I'm looking forward to trying some of this out. Cheers henry |
||||
|
||||
|
Prefect Member since: 8/26/2000 |
|||
|
Posted - 11/11/2001 9:53:21 AM |
||||
| Some thoughts... If you use the IP address another multicast group is receiving, then your application won't receive spurious traffic if you've got a unique port. However, the host will receive the additional traffic, which might lead to congestions on the client side. I assume the IANA (www.iana.org) is responsible for assigning multicast IPs. Note that multicasting isn't the cure-all for your bandwidth needs. For example, in a typical FPS game it is actually the client-side bandwidth which leads to problems. That's why servers only send player information about the players who are next to the receiving client. With multicasting you can't pull off tricks like this, so it might easily congest the client and lead to worse playing experiences. However, multicasting can indeed be useful for data which is intended to be received by all clients anyway, e.g. public voice communication inside the game. It is also very interesting for the ever increasing market of game broadcasts where passive spectators receive the data from a multicast stream. I might also add that the values given as TTL are complete nonsense. The TTL relatesto the number of hops which depends on network topology only not on geography. Of course there are natural similarities. However, I've got more hops to someone using AOL in the next town than I have to some servers in the USA (I live in Germany). The TTL is still useful since low TTL almost always means low ping and low latency. Just don't let yourself be fooled by any false geographical meanings. cu, Prefect |
||||
|
||||
|
Voxelsoft Member since: 12/17/2000 From: York, UK |
|||
|
Posted - 11/11/2001 10:06:39 AM |
||||
| Prefect, Yep, you're right As for the TTL values, I got those approximate geographical values from MSDN. Thanks, Denis |
||||
|
||||
 |
Gaiiden GDNet Content Lead Member since: 8/30/2000 From: Lincroft, NJ, United States |
|||
 Posted - 11/11/2001 3:48:00 PM |
||||
| Nice job on the article Glad that we're getting more and more WinSock articles here. Besides mine and yours I belive there are only two others! _________________________________________________________________ Drew Sikora A.K.A. Gaiiden ICQ #: 70449988 AOLIM: DarkPylat Blade Edge Software Staff Member, GDNet Public Relations, Game Institute 3-time Contributing author, Game Design Methods , Charles River Media (coming GDC 2002) Online column - Design Corner at Pixelate IGDC - the International Game Developers Chat! [irc.safemalloc.com #igdc] NJ IGDA Chapter - NJ developers unite!! [Chapter Home | Chapter Forum] |
||||
|
||||
|
Voxelsoft Member since: 12/17/2000 From: York, UK |
|||
|
Posted - 11/11/2001 6:17:45 PM |
||||
| Wow, a compliment from GDNet staff on my first article. Thanks! Well feedback so far has been very positive so I doubt this will be my only article . It's hopefully the first of many. I wish writing articles and essays for English exams was as fun *sigh*. - Denis P.S. o O (I wonder how many articles it'll take to earn op in #gamedev... :p) |
||||
|
||||
|
Daedalus Member since: 1/1/2000 From: Chicago, USA |
|||
 Posted - 11/11/2001 8:34:17 PM |
||||
| Hey, nice article. I was just wondering if anyone can point me to some recent statistics on the number of internet users that presently have multicast support? -Daedalus |
||||
|
||||
|
Voxelsoft Member since: 12/17/2000 From: York, UK |
|||
|
Posted - 11/12/2001 7:24:08 AM |
||||
| I'm not aware of any such statistics, and it is hard to work out. Also, if I support multicasting and you support multicasting it doesn't mean we can use it over the Internet to communicate as an ISP that does not support multicasting may just drop the packets somewhere in-between. Best stick to LAN and optional solutions. - Denis |
||||
|
||||
|
Prefect Member since: 8/26/2000 |
|||
|
Posted - 11/12/2001 12:56:16 PM |
||||
| I know.. those geographical values are even in some RFC.. so what the hell cu, Prefect |
||||
|
||||
|
deepdene Member since: 3/12/2001 From: Australia |
|||
|
Posted - 11/13/2001 8:29:17 PM |
||||
| One thing I noticed is that of recent that Gamedev has been spitting out decent sockets/tcpip articles. This one is no exception. BTW, just in responce to the poster from Austria. There are plenty of Kangaroo's around here.. |
||||
|
||||
|
sig Member since: 11/25/2001 From: Ukraine |
|||
|
Posted - 11/25/2001 1:01:49 PM |
||||
Nice article, heh. I grab my attention to this problem about year ago. Ahh.. It can be very good if it become true someday.  In practice - we have only few corporate broadcast groups in world, which have own registered multicast ip's and they use them to broadcast video/streaming data but only to local (state/region) boundaries. First: you need an ISP, which have multicast router installed. I dont know the statistics, but i think, that not more a 1% of all ISP's support multicasting. Second: your ISP must be connected to other, located nearest multicast routers, so they know about each other and can transmit data to each other. There also lies a problem, when server and client lies in two different multicast networks which don't know about each other - connection between them impossible. But much worser is, that current channel bandwidth between much of ISP's is too small for supporting a good and reliable multicasting. So the third problem is a packet loss: what types games can stay interactive and functional, when about 50% of all traffic between server and client simply loosed? Maybe someday in future we can use multicasting without a problem. I think, all that because a multicasting is not used heavily by big sofware vendors and internet content providers, so industry developpers of multicasting have small interest in further improvement of multicasting and making it worldwide. By the way: we got same situation with IPv6 - have a standard, but no one cares about it P.S. I found M$DN explanation about TTL very funny. |
||||
|
||||
|
Voxelsoft Member since: 12/17/2000 From: York, UK |
|||
 Posted - 4/15/2004 8:55:49 AM |
||||
| A note to say that the article has just been updated. Added stuff to 'The Darker Side' and 'Sending Multicast Data Packets' sections, might be worth a re-read. Some minor tech/typo corrections too Thanks, - Denis |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
