Apple werkt aan verbeterde versie Bonjour
Apple werkt met de Internet Engineering Task Force aan een verbeterde versie van Bonjour. Op dit moment lopen beheerders van zakelijke netwerken aan tegen de beperkingen van de technologie; deze werkt niet over verschillende subnets.
De bedenker van Bonjour, Stuart Cheshire, heeft daarom voorgesteld om een nieuwe standaard te ontwikkelen voor een verbeterde versie van Bonjour, schrijft NetworkWorld. Bonjour is de merknaam die Apple gebruikt voor een verzameling technieken die mogelijkheden op een netwerk bieden zonder dat er iets hoeft te worden ingesteld, zoals de mogelijkheid om een opdracht naar een printer te verzenden of via AirPlay beeld naar een Apple TV te verzenden. Bonjour leunt op de standaarden dns service discovery en multicast-dns.
Bonjour is opgezet met kleine netwerken in het achterhoofd, maar beheerders van grote netwerken lopen nu tegen de beperkingen van het protocol aan. Het is niet mogelijk om via Bonjour een verbinding te leggen met een host op een ander subnet, waardoor gebruikers op grotere netwerken voor problemen komen te staan. Een presentatie streamen naar een Apple TV die aan een andere router hangt, is daardoor namelijk niet mogelijk. Daarnaast levert Apple-apparatuur op dergelijke netwerken een vloed aan nutteloos multicast-dns-verkeer op, wat leidt tot hoofdbrekens bij beheerders.
Een belangenorganisatie van it-medewerkers op universiteiten is in augustus een petitie begonnen waarin Apple wordt opgeroepen de problemen op te lossen. Apple heeft aan die oproep gehoor gegeven, zo zegt Cheshire tegenover NetworkWorld. In een voorstel voor de nieuwe standaard dat bij de IETF is ingediend, beschrijft Cheshire de nieuwe standaard, die ook meer schaalbaar moet zijn.
Reacties (132)
Volgens mij omschrijf je zelf precies het probleem. Het onvermogen van de technische afdeling om uit die ivoren superieuriteitstoren te stappen en eens realistisch te zijn. Als ze het interesseerden waren ze zelf wel techneut geworden. Wat had je dan verwacht?
Apple is niet een bedrijf dat zich in het algemeen richt op Enterprise-achtige omgevingen. Het is daarom niet zo vreemd dat Bonjour alleen geschikt is voor kleinere netwerken. Bonjour is vooral ontwikkeld om het aanleggen van netwerken even eenvoudig (zo niet eenvoudiger) te maken als het originele AppleTalk protocol. AppleTalk was nooit gericht op grote netwerk omgevingen, het was altijd bedoelt voor thuisgebruik en misschien MKB-achtige omgevingen.Als laatste wil ik even kwijt dat Apple nu herkent dat bonjour beperkingen heeft!
Software ontwikkelen voor alle mogelijke situaties is vrij zinloos omdat:
a) je nooit zeker weet of iedere mogelijke situatie in de praktijk relevant is.
b) de software ingewikkelder wordt om te testen.
c) de software duurder wordt om te ontwikkelen.
Bij de ontwikkelingen van Bonjour heeft men uiteraard gekeken naar hun doelgroep en de software was daarop afgestemd. En voor gewoon thuisgebruik werkt het inderdaad uitstekend. Echter nu iOS devices steeds populairder worden en men binnen bedrijven ook goed gebruik van deze apparatuur wilt maken (een situatie die nooit voorzien was en wellicht ook nooit voorzien had kunnen worden), loopt men tegen de beperkingen van Bonjour aan.
Nee, stel je voor dat iemand de tools kan gebruiken waarmee je het meest efficient en prettig mee werkt... dat wil je niet. Je wilt natuurlijk dat de systeembeheerder bedenkt welke tools anderen gebruiken (ook al kan hij zelf dat werk niet) want anders bestaat het gevaar dat er iets stuk gaat (of zo?).
Je bent ook voorstander er van om servicemonteurs alleen een schroevendraaier te geven, want anders moet de organisatie ook hamers, nijptangen en zagen ondersteunen? Een systeembeheerder is een ondersteunende functie die dingen mogelijk moet maken. Dat is iets anders dan zaken per definitie te verbieden, waarbij dan in 90% van de gevallen de 'voorkeur' van de systeembeheerder belangrijker is dan metrics (en dat is dan niet alleen 'hoeveel kan iets gebruikt worden', maar ook 'als ik apparaat xyz mag gebruiken dan kan ik aantonen dat mijn efficiency met 10% toeneemt'). En systeembeheerders kunnen wel moe worden van het feit dat 'anderen' binnen het bedrijf het geld verdienen, uiteindelijk is dat wel het geval. Had je maar geen ondersteunend beroep moeten nemen.
Je bent ook voorstander er van om servicemonteurs alleen een schroevendraaier te geven, want anders moet de organisatie ook hamers, nijptangen en zagen ondersteunen? Een systeembeheerder is een ondersteunende functie die dingen mogelijk moet maken. Dat is iets anders dan zaken per definitie te verbieden, waarbij dan in 90% van de gevallen de 'voorkeur' van de systeembeheerder belangrijker is dan metrics (en dat is dan niet alleen 'hoeveel kan iets gebruikt worden', maar ook 'als ik apparaat xyz mag gebruiken dan kan ik aantonen dat mijn efficiency met 10% toeneemt'). En systeembeheerders kunnen wel moe worden van het feit dat 'anderen' binnen het bedrijf het geld verdienen, uiteindelijk is dat wel het geval. Had je maar geen ondersteunend beroep moeten nemen.
Het is ook niet echt zeuren, ik werk voor een bedrijf van 45.000 medewerkers en Bonjour staat gewoon op de verboden software lijst door de beperkingen, ik denk ook niet dat die der snel af gaat. Je wil alleen dingen hebben die echt werken binnen je bedrijf en als ze niet geschikt zijn, helaas dan niet.
Dan zit het dus niet in een hogere laag want het bemoeit zich met de lagere laag. Iaw schendt bonjour de gelaagde opbouw van het OSI model. Kijk maar: ( http://en.wikipedia.org/w...I-model-Communication.svg ) als er verbindingen zaten anders dan omhoog en omlaag dan zou men niet spreken van 'layers' maar van 'modules'. Zoals arjankoole hierboven zegt, het OSI model wordt doorgaans niet gerespecteerd. Maar die gelaagde opbouw is juist wat garanties kan bieden tav betrouwbaarheid en veiligheid. Het hele punt van Bonjour is dat je géén DNS server nodig hebt. Het overbelast het netwerk met multicast spam, alleen maar zodat Apple producten elkaar kunnen vinden zonder netjes gebruik te maken van de (bedrijfs-)DNS server. Hoe wil je dat in een corporate omgeving goedpraten? En als je een netwerkprinter in een kantoor zet dan hang je er gewoon een bordje bij met het IP adres (en de netwerknaam). Daar kan iedereen gebruik van maken die bereid is een nummer in te toetsen.
Klinkt hetzelfde ja, er zit allebei een B en een O in de naam... 
Wat een hoop onzin weer bij dit topic, het gaat over een reuze handig netwerk protocol dat ook op linux veel gebruikt wordt (daar geimplementeerd door avahi), maar ik zie dat er alweer hele groepen in de cynische zeikmodus zijn gesprongen omdat het iets is wat door Apple gebruikt wordt. Niet nodig, rommel op het netwerk, hetzelfde als een of ander compleet ander protocol dat zogenaamd wel een 'open standaard is', enzovoorts.
Stel je eens voor dat het gewoon handige technologie is waar een hoop van de zelfverklaarde experts hier waarschijnlijk vaker van profiteren dan ze zelf doorhebben, van Apple. De horror!
Wat een hoop onzin weer bij dit topic, het gaat over een reuze handig netwerk protocol dat ook op linux veel gebruikt wordt (daar geimplementeerd door avahi), maar ik zie dat er alweer hele groepen in de cynische zeikmodus zijn gesprongen omdat het iets is wat door Apple gebruikt wordt. Niet nodig, rommel op het netwerk, hetzelfde als een of ander compleet ander protocol dat zogenaamd wel een 'open standaard is', enzovoorts.
Stel je eens voor dat het gewoon handige technologie is waar een hoop van de zelfverklaarde experts hier waarschijnlijk vaker van profiteren dan ze zelf doorhebben, van Apple. De horror!
Bonjour, een van de eerste zaken die ik uitschakel, als ik een apparaat op een netwerk installeren. Je moet eens met wireshark nakijken, hoeveel broadcasts dat zit uit te sturen, om te zeggen ik ben hier. Op een klein netwerk ga je dat niet merken, maar op een wat groter netwerk wil je die bandbreedte dat je voor al die broadcasts nodig hebt nuttiger gebruiken.
En bvb voor printen, het is misschien wel makkelijk, maar een standaard tcp/ip poort configureren op 9100 is misschien 20 seconden meer werk (zelfs op mac), en je gaat een pak minder overhead sturen om dezelfde printopdracht erdoor te krijgen, dan wat je die zelfde printopdracht er gaat doorkrijgen met bonjour.
Gemakkelijk ? toch niet als het begint mis te gaan op je netwerk.
En bvb voor printen, het is misschien wel makkelijk, maar een standaard tcp/ip poort configureren op 9100 is misschien 20 seconden meer werk (zelfs op mac), en je gaat een pak minder overhead sturen om dezelfde printopdracht erdoor te krijgen, dan wat je die zelfde printopdracht er gaat doorkrijgen met bonjour.
Gemakkelijk ? toch niet als het begint mis te gaan op je netwerk.
Ik denk dat dit probleem vooral in jouw hoofd zit, want uit pure nieuwsgierigheid ben ik eens gaan zoeken of er voorbeelden te vinden zijn van netwerken die langzamer worden door Bonjour en multicast DNS, en die zijn gewoon niet te vinden. Het is een UDP protocol, dus als je switches en routers fatsoenlijk zijn ingesteld krijgen die multicast packets geen prioriteit als het netwerk zwaar belast wordt. De CPU load van 'alles wat een netwerk kaart heeft in je netwerk' komt misschien wel op een dikke 0.0001% uit van die paar packets die af en toe naar /dev/null gestuurd moeten worden, daar zullen gebruikers inderdaad echt veel last van hebben.
Wat ik me afvraag is of je bij alle 1001 soorten netwerk verkeer die je op een typisch corporate Windows netwerk tegenkomt ook als een detective alle packets gaat zitten inspecteren om te beslissen of ze nodig of gewenst zijn? Het zou me niks verbazen als Microsoft gewoon standaard een 1-op-1 equivalent van Bonjour heeft draaien op elke Windows computer. Hoe dan ook, als mijn computer op het werk sloom is dan komt dat 99 van de 100 keer door allerhande aan Windows gerelateerde ellende die niks met mijn werk te maken heeft, niet omdat er een paar UDP packets op de lijn staan waar de computer aan hangt.
Wat ik me afvraag is of je bij alle 1001 soorten netwerk verkeer die je op een typisch corporate Windows netwerk tegenkomt ook als een detective alle packets gaat zitten inspecteren om te beslissen of ze nodig of gewenst zijn? Het zou me niks verbazen als Microsoft gewoon standaard een 1-op-1 equivalent van Bonjour heeft draaien op elke Windows computer. Hoe dan ook, als mijn computer op het werk sloom is dan komt dat 99 van de 100 keer door allerhande aan Windows gerelateerde ellende die niks met mijn werk te maken heeft, niet omdat er een paar UDP packets op de lijn staan waar de computer aan hangt.
[Reactie gewijzigd door johnbetonschaar op vrijdag 9 november 2012 10:23]
Je moet echt _heel_ erg veel pings naar een PC sturen om hem plat te krijgen, dat is echt geen vergelijking. Echt tienduizenden packets per seconde, met maximale payload size. Ik heb het vroeger zelf nog geprobeerd om mijn huisgenoten te etteren, dat waren toen nog computertjes met een 233 Mhz Pentium MMX op Windows 95, en die kreeg je zelfs met 3 computers tegelijk niet plat. Komt nog bij dat ping een ICMP protocol is dat betrouwbaar gerouteerd moet worden, terwijl Bonjour UDP is, dat by design een onbetrouwbaar protocol is, en routers naar believen mogen droppen als het netwerk overbelast raakt. Ik ken de precieze details van Bonjour niet, maar ik stel me zo voor dat apparaten die zich met Bonjour announcen dat eens in de zoveel seconden doen, niet 10 duizend keer per seconde. Ik zie in ieder geval vaak een seconde of 30 delay tussen het aanzetten van bijvoorbeeld mijn MacBook voordat ie op mijn andere Mac verschijnt. Vergeleken met de gigabytes aan andere traffic die er elke seconde over een beetje netwerk gaan echt peanuts.
Ik ben het in zoverre met je eens dat als jij 200 printers in je netwerk hebt hangen die via een print server beheerd worden, en alle clients van te voren netjes kunt configureren, dat je ze dan niet voor jan joker allemaal via Bonjour gaat laten announcen. Maargoed dat geldt voor elk soort network service dat je niet gebruikt.
Ik ben het in zoverre met je eens dat als jij 200 printers in je netwerk hebt hangen die via een print server beheerd worden, en alle clients van te voren netjes kunt configureren, dat je ze dan niet voor jan joker allemaal via Bonjour gaat laten announcen. Maargoed dat geldt voor elk soort network service dat je niet gebruikt.
[Reactie gewijzigd door johnbetonschaar op vrijdag 9 november 2012 11:09]
Juist. Jij hebt 1 iTunes draaien op je thuisnetwerk, net als miljoenen andere mensen die geen enkel probleem hebben met hun netwerk, en het blijkt een probleem in de uClinux kernel te zijn dat gepatched kan worden, maar:Na lang zoeken bleek het een probleem te zijn met de ip stack van uClinux.
[..]
Gelukkig kwam er een patch beschikbaar voor uClinux.
het bonjour protocol is wel degelijk de oorzaak voor m'n netwerk problemen thuis.
Ik draai thuis een SqueezeCenter met een Squeezebox eraan (announcen allebei via avahi, dus Bonjour), een time capsule (Bonjour), een iTunes library op een 24/7 home server, vaak 2 Macs met iTunes open en AirDrop aan (Bonjour), een router met een een shared volume die zich automatisch announced (avahi), een iPad en een iPhone die via AirPlay (Bonjour) zowel als host als target kunnen connecten met XBMC (avahi), en dat vrijwel volledig over WiFi, zonder ooit met 1 vinger aan enige netwerkinstelling te komen, en toch haal ik dik over de 100 Mbit/s als ik wat bestandjes over kopieer. Rara hoe kan dat?
Ik denk toch dat jouw probleem niet bij Bonjour ligt...
Sorry, maar dit is onzin. Ten eerste werkt Bonjour met multicast, niet met broadcast. Precies om te zorgen dat hosts die geen interesse hebben in een multicast stream die gebroadcast wordt om technische redenen (zoals dat op ethernet vaak gebeurt met multicastverkeer), hebben ethernet interfaces filters die ze kunnen zetten op destination MAC adres. Dat kost zo'n kaart nauwelijks moeite en tenzij de kaart in promiscuous mode gezet is door de host, heeft de CPU niet eens door dat er een multicast packet langs kwam.Ik kom bij genoeg bedrijven waar ik hoor klagen, dat de mensen hun pc trager werkt, als hij op het netwerk aangesloten is, dan wat ze hem thuis gebruiken.
Het is goed voor de performantie van een netwerk, van je broadcast domains zo klein mogelijk proberen te houden (en als je dat al doet, printers in een ander broadcast domein, dan je pc's heb je al niks meer aan die bonjour).
En zelfs als je nicdie filter niet heeft, zó veel verkeer is 't nou ook weer niet.
Ik heb dit toevallig getest met een serieuze netwerktester (zo'n ding wat geen enkele moeite heeft met het genereren van vier 10Gbps streams aan willekeurig multicastverkeer; merk helaas even vergeten) en je hebt toch echt flink wat meer verkeer nodig dan jij lijkt te denken om een normale host op z'n knieën te brengen met broadcastverkeer, en met multicastverkeer kán het gewoon niet.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
