Diskussion:Zeroconf
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen, und unterschreibe deinen Beitrag bitte mit
oder --~~~~.Konsolensprech-Hinweise
Hm, Konsolensprech-Hinweise sind für 95% der Nichtexperten sinnlos.
Wie bekommt man das Zeug denn nun ans Laufen? Also der eigentliche Sinn von Zeroconf - nämlich eine unaufwändige Netzwerkfreigabe und Austausch von Daten wird mit diesem Artikel nicht beantwortet. Ist das nicht irgendwie total schrill? -- 87.123.117.135 21:20, 18. Jun. 2007 (CEST)
Wäre es nicht sinnvoller anstatt "Allokation" "Zuweisung" zu verwenden, weil Allokation nur i.w.S. Zuweisung bedeutet und die eigentliche Übersetzung "Platzieren" weitaus weniger als Zuweisung passt? 84.137.230.250 21:57, 31. Okt. 2007 (CET)
Weiss jemand, wie alt das Protokoll ist? Was zur geschichtlichen Entwicklung ist doch immer interessant... 194.88.178.74 13:24, 12. Feb. 2009 (CET)
Es gibt noch eine weitere Methode zur "Vermeidung redundanten Netzwerkverkehrs". Die "Multi-Packet Known Answer Suppression". Steht in http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt unter Punkt 7 bzw 7.2 (was auch eine Quelle wäre für die anderen Möglichkeiten und allem zu mDNS) (nicht signierter Beitrag von 79.211.110.11 (Diskussion | Beiträge) 22:08, 30. Nov. 2009 (CET))
Routing
Wie kommt man ohne DHCP-Server an die IP-Adresse eines Routers? --85.179.252.196 16:31, 14. Apr. 2009 (CEST)
- Gar nicht. Die Addressen sind link-local und können daher nicht geroutet werden. --87.147.33.242 02:02, 26. Sep. 2010 (CEST)
DNS-SD und DNS-Record-Typen
IMHO ist die folgende Aussage am Ende des zweiten Absatzes über Multicast DNS falsch: "DNS-SD dagegen führt einen neuen Typ an DNS-Records ein, sodass..." Der Beleg dafür findet sich in der Einführung des auch als Weblink angegebenen Drafts für DNS-Based Service Discovery:
This document proposes no change to the structure of DNS messages, and no new operation codes, response codes, resource record types, or any other new DNS protocol values. This document simply specifies a convention for how existing resource record types can be named and structured to facilitate service discovery.
Vorschlag: Den betreffenden Satz ändern in "DNS-SD dagegen spezifiziert eine Konvention für die Verwendung von existierenden DNS-Record-Typen, die das Browsen und Veröffentlichen von Netzwerkdiensten mit DNS ermöglicht.
-- DWB 00:19, 22. Sep. 2009 (CEST)
- WP:SM :) Rbrausse (Diskussion Bewertung) 00:22, 22. Sep. 2009 (CEST)
Sie entspricht jedoch nicht dem RFC der IETF.
Bei so einem Satz fehlen leider jegliche Quellen die es belegen und vor allem angeben, was denn bitte abweicht. Wenn der Satz stimmt, bitte erklären, wenn nicht, dann nix wie raus damit! --87.147.33.242 01:57, 26. Sep. 2010 (CEST)
- Ich hab das mal mit einer Quelle versehen. Man vergleiche die IP-Range im Artikel und die aus RFC 3330 und leite daraus die Abweichung der Microsoft-Implementierung von der Spezifikation im RFC ab. -- ak 13:12, 25. Okt. 2010 (CEST)
Formulierung in der Einleitung
Kommt es nu mir so vor oder macht die Formulierung des ersten Satzes nach dem zweiten Absatz irgendwie keinen Sinn? Welches Problem ist gemeint? --VonFernSeher | !? 22:43, 16. Feb. 2011 (CET)
Netzwerkbereich fehlerhaft....
"...von der IANA der Adressbereich 169.254.0.0/16 vorgesehen....wählt er eine IP-Adresse zwischen 169.254.1.0 und 169.254.254.255 aus (RFC 3330)...." Da stimmt doch was nicht....? -- Bitfox:Bitfox 15:43, 18. Jul. 2011 (CEST) (ohne Benutzername signierter Beitrag von 217.150.152.145 (Diskussion) )
- Die Adressbereiche 169.254.0.0 bis 169.254.0.255 und 169.254.255.0 bis 169.254.255.255 sind reserviert, werden aber nicht verwendet: „The first 256 and last 256 addresses in the 169.254/16 prefix are reserved for future use and MUST NOT be selected by a host using this dynamic configuration mechanism.“RFC 3927 Absatz 2.1 --Fomafix 15:55, 18. Jul. 2011 (CEST)
Hm
„Verbindungen in andere Netze als das Internet sind bei all dem ausgeschlossen.“ - was soll das denn heissen? --
itu (Disk) 22:12, 20. Jun. 2015 (CEST)
Konfliktlösung im mDNS
Der Satz "Eine Konfliktlösung wird sogar bewusst nicht diskutiert, da es sinnvolle Anwendungen für den Fall geben kann ..." ist falsch. Beim mDNS ist sogar sehr genau definiert, wie ein Konflikt behandelt wird. Jeder Teilnehmer im Netzwerk, der einen neuen Namen erhält, oder neu im Netzwerk startet, propagiert seinen Namen im Netzwerk. Alle Netzwerkteilnehmer lauschen. Sollte ein Konflikt mit einem existierenden Namen bestehen, so verteidigt der Besitzer seinen Namen. Wenn der neue Teilnehmer den Namen nicht wechselt, so wechselt der bisherige Teilnehmer seinen Namen. Ein Name wird gewechselt, indem am Ende des Namens einige Zeichen angefügt werden. Die Konfliktbehandlung ist sehr wichtig. Nur so kann sichergestellt werden, dass ein Netzwerkteilnehmer mit genau mit dem Teilnehmer kommuniziert, mit dem er vor hat zu kommunizieren. (nicht signierter Beitrag von Bstrueber (Diskussion | Beiträge) 14:50, 7. Aug. 2018)
Adressbereich Link-Local
Der verwendete (IP4-)Adressbereich entspricht 1:1 Link-Local. Der Begriff wurde zumindest in der Diskussion schon mal verwendet. - Sollte man das im Artikel ergänzen? (Leider gibt es eine Seite dazu (noch?) nicht auf Deutsch: https://en.wikipedia.org/wiki/Link-local_address) (nicht signierter Beitrag von 84.59.183.17 (Diskussion) 12:53, 26. Apr. 2022 (CEST))
