Hi,

Recently, I have been going through several researches and topics at this forum but as a result I still have more questions than actual answers which is up to date. That's why I started this new topic.

What I wan't is to form basic understanding of unicasting, multicasting and broadcasting related to TCP vs UDP and how these are used. (Before someone says "there is no such thing as TCP multicast etc, read on..")

To narrow my questions to relevant area, lets assume to be developing online multiplayer game (with client-server model) to work over wide area networks (note: not LANs)

So my questions are below:

Q1: Unicast, multicast and broadcast in TCP and if so, how? if not, how to mimic?

Q2: Unicast, multicast and broadcast in UDP and if so, how? if not, how to mimic?

Q3: This is a bonus question, using TCP and UDP together, is this a myth? or does these conflict somehow and make things even slower?

My own guesses are here:

A1:

- There is no such thing as multicast and broadcast in TCP. TCP is point-to-point connection between server and client. This connection is unicast oriented. Server opens one connection per client and sends game state packet through it. If others needs this information, it needs to be send to those individually, this wastes bandwidth, but this is what we have to accept with TCP.

Unicast:

- Like being said, all communication is unicast oriented, point-to-point. e.g. To send single game state update from server to 3 players in game, it needs to send same game packet total of 3 times.

Multicast:

- Cant be done because of the nature of TCP. If TCP needs to act as a multicast: closest it can get is to use some criteria at server to group players (like again, 3 together) and send to those only. But still, it would need to send same game packet total of 3 times. But its the closest we can get with TCP.

Broadcast:

- Not supported, again.. only way to mimic broadcast is to take all players at server (lets say 10) and send same packet 10 times over.

A2: (Not even close to sure what I am guessing here, but lets try with these):

- There is a unicast, multicast and broadcast in UDP.

Unicast:

- Possible as in TCP. Can send one packet to one client only.

Multicast:

- This is the topic of high concerns, there is like 10 - n researches pointing out facts about multicast, to clarify: IP multicast. There seems to be many applications utilizing multicast, as if its the only real way of data transfer in distributed simulations. However, this is where the interesting point comes in. IP multicast can reduce the traffic because of reaching 3 players with only one packet (this group is based on some IP and port). Sounds too perfect to be true, well it seems that www routers are not supporting this (I read somewhere that only few % of routers supports this), so IP multicasting is not an option either in MOGs ? Or, considering client-server model, does this support needs to be only from game server provider side? ... can it be easily enabled and clients dont need to do anything? And if not... considering all the games using UDP over internet, are those using unicast all the time to send game updates, I guess that broadcasting is not even an option.?

Broadcast:

- Exists in UDP and can be used to broadcast to every connected client from server with just one packet. However not recommended to be used.. maybe in LANs or less critical apps?

A3:

- I have no guesses for this option, I have read that they conflict and slow things up, but I have also read that these can be used together.

Okey, well.. these were my best answers to my own knowledge atm, as can be seen I am most interested about the red text. Based on material what is out there: it seems almost that IP multicast and multicast is completely different things and there is no good support for ip multicast but still multicasting exists somehow for UDP? hmm.

Thnx!

Broadcast and Multicast only work if you control all routers between your server and the client.

ISPs who offers IPTV services often use multicast on their own network and if you are hosting a server or proxy at a big ISPs datacenter you might be able to negotiate for multicast support for your service to that ISPs customers but its not likely to be cheap.

You can get something similar to multicast on the internet by using proxies placed reasonably close to your clients. (your main servers then only send data to the proxies which can pass the data on to multiple clients (possibly using real multicast for that part if the host allows it)

All (or almost all atleast) games use unicast, it is fairly uncommon in games to send the exact same data to a large number of clients, having clients join and leave multicast groups constantly would be very messy and giving every single player all the information would greatly increase the bandwidth required for the clients (if your clients need a 1Gbps connection to play your game you won't get many customers)

Broadcast and Multicast only work if you control all routers between your server and the client.

ISPs who offers IPTV services often use multicast on their own network and if you are hosting a server or proxy at a big ISPs datacenter you might be able to negotiate for multicast support for your service to that ISPs customers but its not likely to be cheap.

You can get something similar to multicast on the internet by using proxies placed reasonably close to your clients. (your main servers then only send data to the proxies which can pass the data on to multiple clients (possibly using real multicast for that part if the host allows it)

Hmm interesting, to this end it seems that true multicasting is hard to achieve and most researches have been testing it by using LAN setup's.. which in turn doesn't really reflect to real world. (how hard its to get correct infrastructure to make it all work).

how hard its to get correct infrastructure to make it all work

The problem is not "get correct infrastructure," then problem is that IP multicast is a fundamentally broken concept outside a controlled LAN.

Consider:
Alice and Bob start up a multicast group. The routers between Alice and Bob must know about this group; this can probably be cheaply arranged (a single session setup packet.)
Now, Charlie wants to join this group. How does Charlie's router know about the Alice/Bob multicast session? How does this router discover the route to that destinagion?
The answer, as specified, is that <b>every router on the internet needs to know about every potential multicast group</b>. This can never work in practice, as by design it does not scale!

Separately, TCP cannot do broadcast, because it is a protocol that keeps state between two endpoints. "Broadcast" doesn't make sense as a concept in this context.

A1 and A2 have the same answers. You need to build meshes between the machines and relay the messages yourself. You can build fully-connected meshes where everyone talks to everyone, you can build partially connected meshes where some people talk to other people and they need to carefully relay meshes to those they connect, you can build publicly-visible repeaters so that people can fake a fully-connected mesh, you can implement a star where one machine is designated the server and everyone must have connectivity to it, or just about any other layout you can imagine. The logical topology of a network does not need to match its physical topology. Depending on your logical topology you might be able to reduce bandwidth requirements by merging messages if you know they share a communication route.

A3 is pretty fun. Yes, you can mix TCP, UDP, and other protocols within a single application.

Many beginners write their code based on having a single connection between machines.

While it is certainly possible to write code that way, nothing prevents you from making multiple connections.

As a simple example, many games have voice chat and implement the feature by simply dropping in a 3rd party voice chat library. That library creates its own UDP connections, builds its own mesh, and otherwise operates independently of the game's communication system. As another simple example, I can open up lots of instances of a web browser, or lots of tabs, each one connecting to the same server on separate connections.

If your game design works well by having a TCP connection as well as a UDP connection, that is certainly an option. If your design is such that you have multiple independent communication meshes, you can have a connection for each one. The thing that immediately jumps to mind is file transfers; you can make one connection per file, much like FTP, so that you effectively have a launcher connection and several individual worker connections. You might have multiple web connections, multiple telnet sessions, multiple SQL server connections, or combinations of all of them at once.


If you want to establish multiple connection channels while ensuring that connectivity remains consistent, build a protocol that establishes reliable UDP. You can also find existing packages that do this. Basically they set up a protocol with their own headers attached to packets, and the added headers allow for sub-channels. They can then write some custom protocol code that marks if the sub-channel must be reliable or not, and for reliable channels implement their own system of sliding windows, ACKs and NAKs, and all the other necessary pieces so they can retransmit the reliable sub-channels while handling unreliable sub-channels in a regular UDP manner.

Yes, thnx for all the replies. This all makes sense now!