Talk:Multicast

Widely Deployed

"IP Multicast is widely deployed..." -- I think this is misleading, Fabiovh (talk) 14:27, 23 February 2009 (UTC)

Reliable Multicast

Would anybody care to add an overview of reliable multicast?

What about a list of links for a start? --SymlynX

Broadcast isn't Multicast

And what's the difference to broadcast, as in "broadcast adress x.x.x.255"? --Abdull 08:38, 30 May 2005 (UTC)

Others can correct if I am wrong. I suppose you can think of multicast as a controlled or selective way of broadcasting over a wide area network (not just within the loca area network).

The broadcast address in a IP subnet (which x.x.x.255 is one example) can only be used to talk to all hosts the local broadcast domain (eg on a Ethernet LAN). This address maps directly to broadcast address like Ethernet's ff:ff:ff:ff:ff:ff address. Any packets to this address does not go outside the IP subnet.

This is in contrast to multicast, which allows sending packets to all nodes which subscribe to a particular multicast ip address/

--sdf

The technical details of IP Multicast allow you to use that technology for local broadcasts. However when you do so, you are NOT multicasting. Broadcast tries to deliver something to everybody while multicast focuses on those, who actually want that information. -lynX

I'm currently writing on a chapter about how broadcasting (tv/radio stations) evolved to multicasting on the internet, also describing things like broadcast domains in a rather simple matter. I'd rewrite it to fit in this article if that's appreciated... -def

Routers are layer 3 devices that do not use spanning tree protocol.

Security

The article says: "... applying that to IP Multicast traffic would enable any of the receivers to pose as the sender. This is clearly unacceptable".

How is it possilbe to pose as the sender? Can anyone please explain why is it unacceptable in a language that will be understood by someone who's not a cryptography expert?--Amir E. Aharoni 07:47, August 29, 2005 (UTC)

This article is lacking substantially in several parts. Just to point out something on multicast (group) security, what makes this all so challenging is finding efficient algorithms for (1) key management (for assuring confidentiality within dynamic groups) and (2) source authentication. What the paragraph about security issues is talking about is the problem of using symmetric keys for authentication which only allows GROUP authentication (vs. source authentication). The cited sentence should rather say something like "Use of symmetric keys for authentication would enable any of the receivers to IMPERSONATE the sender.". Asymmetric cryptography on the other hand in turn is too heavy for most applications (low computing power, high throughput, etc.). TESLA is one of the promising new efficient algorithms for SOURCE authentication. This article is not mentioning key managment algorithms whose most promising one is LKH (Logical Key Hierarchy). Regards, Michael Noisternig

Web conferencing

The Web conferencing link is somewhat problematic. The term itself is inaccurate, and many mentioned technologies on that page do NOT multicast. Should we pick the technologies that actually multicast, and link them from here? -lynX

Sincerely I don't see any technology on that page using multicast in any way, so I removed it. --SymlynX 06:24, 4 May 2006 (UTC)

Instant messaging

Instant messaging is to a large amount a one-to-many medium. Even if people aren't engaging in chatrooms all the time, every change in presence status is sent to all "buddies". Yet none of the technologies used to that purpose implement any multicasting as they should, no surprise they either have to operate in a centralized way, which defeats privacy, or cannot scale properly when operating in a decentralized way. Don't you think this problematic fact needs mentioning in both documents? -lynX

IRC uses Multicast?

The article mentions that IRC uses Multicast, but does it? I dont think it does, atleast not apparant to the end-user? More specifically mIRC uses only TCP, as far as I've seen.

• Multicast most definitely is not used by IRC. IRC is structured in a way that would benefit from using multicast, because it's slightly reinventing the wheel (less netsplits and so forth), but it's not actually used by IRC. --82.1.178.244 20:18, 4 March 2006 (UTC)

• IRC does not use IP Multicast. But the role of a channel is one similar to a multicast group. See also section 5.2.1 of RFC 2810.

• Please don't confuse Multicast with IP Multicast! The IRC Network is a simplistic multicast structure which is however probably the most successful multicast application on the Internet today, second only to some local network uses of IP Multicast, which do not count as multicasting, because they are actually local broadcasts. --SymlynX

I'll try and help

1. Broadcast is a special multicast group. That is an all hosts group. In IPv4 there are actually two distinct forms of a broadcast address. The first is the limited local broadcast address of the form 255.255.255.255. When an IP datagram is sent to this destination, it is sent to all hosts on the local network. Datagrams to this destination will not be forwarded by a router. The second form is the directed broadcast address and the actual destination IP address depends on the network being referred to. Generally speaking we say that the network bits are set to the network address of the destination network and the host bits are set to all binary 1's. For for example, if you want to send a broadcast to all hosts on the 192.0.2.0/24 network, you set use the network bits to the network address, which in this case is just the first three octets (192.0.2) and the host bits, the last octet to 255, resulting in final destination address of 192.0.2.255. What would be the directed broadcast address for 192.0.2.0/25? 192.0.2.127.

Broadcasting is the concept of delivering a message to all destinations on a network with an unspecified amount of listeners actually using it. You are only talking about a particular type of Broadcast. --SymlynX 06:30, 4 May 2006 (UTC)

2. I'm not sure what is meant by "pose as the sender" comment. I think they are essentially saying that if you let everyone in the group share the same key, then how do you know who the actual sender is. This is actually a separate problem and the original author I think is a little confused. That part needs to be ripped out and changed completely.

3. Web conferencing, instant messaging and IRC are hardly multicast technologies as the term multicast is commonly used. Again, I think someone is confused. Those need to be ripped out.

Web conferencing and instant messaging should do some multicasting (not IP Multicast though, as it isn't real world feasible). IRC multicasts. --SymlynX 06:30, 4 May 2006 (UTC)

I will plan on doing a major update of this article shortly.

Simply Bad Writing

It seems that the writer of this article does not have a good grasp of English and/or of writing in general. I would prefer an article written by a native speaker who can construct a grammatically correct sentence.

This article is lacking seriously.

Multicast and the protocols surrounding multicast snooping and routing have been widely implemented in almost every network vendors equipment (accept for the more entry level devices). Multicast scales very well across the LAN/WAN (if the network supports it). A 5mbps MPEG stream could be sent to ever user on a network while only using 1 x 5mbps worth of bandwidth on any one link.

Yes we could use a distinction there. IP Multicast scales well for a small amount of large transmissions, but it scales very badly for a large amount of small transmissions. It wouldn't be able to handle every Internet chatroom as it should, or was part of the original intention over a decade ago. PIM/SM was intended to address that, but failed. We chat developers were hoping for such a platform to build the next IRC upon (and we were at the IETF meetings talking about it), instead today we must recognize IRC is still the most popular and pragmatic solution, while IM technology hasn't even understood the multicast concept. --SymlynX 06:47, 4 May 2006 (UTC)

The reason that the internet doesn't support multicast (don't forget the MBONE) is not because of the protocols as much as it would require a massive configuration change and upgrades globally to implement the protocols. Which mean that every phone company, ISP, cable company, DSL and Cable modem manufacturer would have to be on board and agree to make the changes at the same time. Never going to happen.

That is why, in part, the Internet 2 came to be. The I2 (like the original internet) connects universities, k-12 and government agencies together on high bandwidth connections. The entire I2 is multicast enabled. This means that if a video is being multicast from NYU, someone can watch at Berkley, Bowling Green.

Yes go ahead and update all the facts on IP Multicast. It is probably a good idea to do it in the IP Multicast document that somebody legitimately created. Why would you want to deprive Multicast of its abstract meaning and IP Multicast from being different from the concept of multicasting itself? After all the term existed before IP Multicast was invented. It's as if Santa Claus were redefined as wearing red just because Coca-Cola preferred him red over the original blue. --SymlynX

Warcraft in between?

Multicast is also a term used on a Warcraft 3 map known as Defense of the Ancients. It is a passive spell used by the Ogre Magi that gives him a chance to, as the term suggests, multicast his spells onto targets.
If this is really information someone is looking for, it definitly belongs into a seperate entry.

Make a disambiguation page. Cbdorsett 06:28, 25 January 2007 (UTC)

Move content to IP Multicast

There seems to be no objections to merging the IP multicast content from this page onto the separate IP Multicast entry. Given that there are two entries (and I think it makes sense for there to be two), it doesn't make sense for the majority of the content on IP multicast to be here. So I'm moving it. Stephen.frede 06:51, 11 July 2006 (UTC)

OK, move is done. I actually ended up rewriting most of the content. See IP Multicast. Stephen.frede 10:29, 11 July 2006 (UTC)

There were still some parts related to IP Multicast in here, I have moved them into Talk:IP Multicast if you'd like to integrate them into that document. I also reverted the edits by Jtk. Apparently (s)he has never heard about other Multicast applications than IP Multicast, but that shouldn't be our problem. -SymlynX 11:13, 7 September 2006 (UTC)

Someone who claims "IP Multicast, which do not count as multicasting, because they are actually local broadcasts" I would suggest has a bit of a problem understanding IP multicast and that is our problem, but I give up, go on calling it IRC multicast and other made up silliness if you insist, hopefully cluefull folks will drop over to the discussion page and will see that there is someone who arguably knows a thing or two about multicast takes issue with what you're writing. jtk Wed Nov 22 06:50:11 UTC 2006

My current state of information is there are uses of the IP Multicast protocol and addresses for simple LAN broadcast uses, thus not actually making use of the actual purposes of the protocol. If that is wrong, please update that part. Concerning IRC's spanning tree distribution, how would you argue this not to be multicast? I can understand if you don't agree on the XMPP XEP-0033 extension using the word multicast just because it has the ability to carry a list of recipients, but IRC does indeed implement a routing strategy. Please explain your point of view. --SymlynX 15:55, 26 November 2006 (UTC)

Note to JTK: Please do not give up. I came to this page to get an understanding of the topic. I did not expect the info to be all wrapped up in a pretty bow. Neither did I expect to find any silliness. If you think the present edition is confusing or factually erroneous, I for one will thank you for helping clear it all up. An editor's job may be thankless, but that's what the job is: clearing things up. In the meantime, I'll go back to prizing the gems out of the muck. That's what a reader's job is ... Cbdorsett 06:37, 25 January 2007 (UTC)

What is the status of this merge initiative? At present, this article is almost exclusively about IP multicast. It even says so in the introduction - The word "multicast" is typically used to refer to IP multicast. --Kvng (talk) 16:56, 21 August 2008 (UTC)

XCAST

I managed to find a little information on this japanese development, yet most links point to 404. Is this technology more than just a legend? What happened to the IBM implementation? Is there an XCAST for IPv4 at all? Do implementations only exist for FreeBSD? ---SymlynX 04:28, 17 September 2006 (UTC)

Update: XCAST appears to be an IP Multicast compatible API that explicitely lists the distribution tree rather than using the regular mechanisms of IP Multicast. Yet it seems to do a multicast type of distribution. Hard to tell if this is properly placed here or rather in the IP Multicast article. What do you think? Should we mention it at all if it doesn't seem to be neither available nor in use? --SymlynX 16:07, 26 November 2006 (UTC)

Windows Media Player multicast?

What is Windows Media Player multicast?--Hhielscher 19:57, 17 November 2006 (UTC)

never heard of --SymlynX

The Windows Media player (and the server for that matter) support multicast for the distribution of content using RTSP. See Microsoft Media Services --Javifs —Preceding comment was added at 15:21, 21 November 2007 (UTC)

Edits worth reverting?

I don't know what the intention of this edit is, but I think the original version made more sense. Revert? --lynX 11:23, 24 January 2007 (UTC)

Personally, I think the entire article needs a going over. Revert it if you want, but I think it's just a drop in the bucket. Just be aware there is a Wiki subculture out there who subscribe to the view that reverts should be used only for vandalism, and you should be prepared for their ire. Cbdorsett 06:33, 25 January 2007 (UTC)

Confusing Labels in Figure

In the "Routing Schemes" figure, it's unclear whether the labels ("anycast", "broadcast", etc.) correspond to the illustration above or to the one below (below is what's intended, I believe). This is especially confusing if the figure is read from top to bottom. DRE 19:01, 30 May 2007 (UTC)

I created a new one. Still confusing? --Easyas12c 22:59, 31 May 2007 (UTC)

No, now it's quite clear. Thanks! DRE 21:31, 27 July 2007 (UTC)

Do XMPP and SMTP multicast?

In a protocol extension numbered XEP 0033 XMPP authors claim the word multicast for a syntax sending one message to multiple recipients in an equivalent way to SMTP's Cc: headers. If this isn't improper use of the word multicast, we must also mention SMTP being a multicast protocol as it operates exactly in the same way. Opinions? --lynX

Multicast in TCP?

Is it possible to do multicasting with TCP? —Preceding unsigned comment added by 89.180.136.16 (talk) 22:46, 21 May 2008 (UTC)

If you mean 'Can u do _IP_ multicast with TCP', no. plain TCP requires the sender & receiver to establish a 3 way handshake and this is only between two parties. TCP also uses other mechanisms for flow control etc which are geared towards a two party only config. Having said that TCP maybe used to setup multicast topologies in higher layers (see above discussions on IRC etc). There might also be other reliable & possiblly connection oriented layer 4 protocols that support IP multicast. 203.173.11.157 (talk) 09:29, 22 May 2008 (UTC)