Talk:IP Multicast
From Wikipedia, the free encyclopedia
Contents |
[edit] Moving Addressing to Routing Schemes
I think the Addressing section should be moved. At least some of it. Those things relevant to multicasting are ok, but anycasts or unicasts have hardly anything to do with IP Multicasting. Opinions? -def Mon Jul 24 2006
[edit] Cleanup notice
Gah. Product boosting and advertising blather. Not the hottest writing either. I don't have time today to clean it up, but I'll try to take a crack at it Real Soon Now. Anville 21:58, 22 August 2005 (UTC)
Tossed in a very brief overview on the Temp page. Provides a brief definition and some vendor-neutral technical details. Since I wrote the whole thing myself, it should be immune to copyright violations. Of course, that doesn't necessarily mean it's good enough quality...196.41.167.243 12:01, 24 August 2005 (UTC)
It seems that the writer of this article does not have a good grasp of the English language. I would prefer an article written by a native speaker.
<SymlynX> I haven't created this document, but it makes sense to me to have distinct documents for IP Multicast and the abstract meaning of Multicast, so I'm positive for a merge of the IP Multicast part in Multicast into here. What do you think?
@SymlynX: Makes sense to do so...
Seems good. --anonymous
[edit] Rewrite
I have merged the content from Multicast, but ended up rewriting most of it. Sadly wasn't signed in when I made the change, but 2006-07-11 21:08:36 203.2.96.1 was me. It still needs work, but it's better than it was. Stephen.frede 10:14, 11 July 2006 (UTC)
[edit] Complete update started
It's going to take quite a bit of doing as IP multicast is a pretty large subject, but I made a start at it today in the first few sections. Long way to go and a lot of ground to cover, but hopefully I can get it done. Hopefully none of the past editors take offense to my going gung ho, but I hope you'll find my contributions worthwhile. I think you'll find I have a fair bit of multicast expertise, but feel free to challenge me if there is something major you don't like. I do expect to have some bits and pieces fixed up by others as my writing can sometimes be a little hectic and not always well organized as I move from topic to topic. [ update: silly cookie, expired, this is me jtk ]
While at it, multicast security [MSEC] is another topic missing. --anonymous
[edit] Inappropriate Tone
The use of second-person conversational tone as well as several other unencyclopaedic statements is inappropriate. The text of this article be revised.
For example: "You might now be wondering about the efficiency..."
go ahead and change the tone where you find it lacking, but please be careful with the technical details, that is the part I am focusing on jtk Sun Jul 23 03:41:15 GMT 2006
Changed a few of the tone thingies -def Mon Jul
Some of the multicast security work (particularly relatated to crypto and group authentication) might be well suited for a separate article. Much of that work is academic and not widely deployed. I know less about it, so if someone wants to take a stab at it go for. Though I can envision that being a separate article as I said. jtk Fri Sep 1 15:52:49 GMT 2006
[edit] Integrate these paragraphs?
The following text blocks stem from the Multicast document but since they are about IP Multicast they don't belong there. Feel free to integrate in this document. -SymlynX 11:09, 7 September 2006 (UTC)
Link local multicast, where IP Multicast packets are sent to groups of hosts on the same physical or virtual data link layer, does not require complex routing, and is therefore much more widely deployed. It is used in IPv6 for address resolution, and in zeroconf networks for service discovery, name resolution, and address conflict resolution, replacing inefficient broadcast protocols.
Multicast security is a major issue. Standard, practical, communications security solutions normally employ symmetric cryptography. But applying that to IP Multicast traffic would enable any of the receivers to pose as the sender. The IETF MSEC workgroup is developing security protocols to solve this problem, mostly within the architectural framework of the IPsec protocol suite.
IPsec cannot be used in the multicast scenario because IPsec security associations are bound to two hosts and not many. IETF proposed a new protocol TESLA, which is quite convincing and flexible for multicast security.
Multicast security has been an active area of interest for some time. Standard, practical, communications security solutions normally employ symmetric cryptography. But applying that to IP Multicast traffic would enable any of the receivers to pose as the sender. The IETF MSEC workgroup is developing security protocols to solve this problem, mostly within the architectural framework of the IPsec protocol suite.
[edit] Hoot-n-holler?
Can anyone say what a "hoot-n-holler" system is? The article refers to it, but Wikipedia doesn't have an entry.... --Alvestrand 06:41, 22 September 2006 (UTC)
- Found a def. [1]. Now to make an article from it... --Alvestrand 06:43, 22 September 2006 (UTC)
[edit] Applications and Protocols?
There are currently no links between this topic and the topics covering applications using multicast.
At least the "Applications" paragraph could note that "multicast is supported by protocols such as Real Time Streaming Protocol and applications such as Windows Media Player". I'd add this myself, but the discussion page indicates that people have spent quite some time tidying this page up.
Thog 203.59.28.111 07:01, 27 October 2006 (UTC)
