Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 132 reacties, 32.282 views •

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)

Reactiefilter:-11320125+173+215+32
Moderatie-faq Wijzig weergave
Biedt DLNA niet praktisch dezelfde mogelijkheden :? Enkel is dat natuurlijk universeel....
Biedt DLNA niet praktisch dezelfde mogelijkheden :? Enkel is dat natuurlijk universeel....
Ik denk dat je nu bonjour en AirPlay door elkaar haalt. Een van de grote voordelen van DLNA is dat het redelijk universeel is, maar het nadeel is dat het niet zomaar werkt. Als jij via DNLA een MKV voert aan een willekeurig apparaat (laten we een willekeurige denon receiver nemen van een jaar oud), is de kans redelijk groot dat dat apparaat er niets van snapt. DNLA dwingt namelijk nergens dingen af als codecs of timing. Dat doet AirPlay wel, en dat maakt het veel eenvoudiger in het gebruik voor de niet tweakers. (Je weet wel, 99,99% van de wereldbevolking)

Als ik m'n vriendin zou moeten uitleggen hoe ze zoiets met DNLA zou moeten doen, zou ze me uitlachen en vertellen dat het geen goede oplossing is. De appleTV en AirPlay dingen hoef ik haar niet eens uit te leggen, want die werken gewoon. En dan is m'n vriendin nog een uitzonderlijk intelligent persoon ook. De eindconclusie is derhalve ook: buiten enkele tweakers interesseert open en universeel totaal niet. Het mot werken, punt.
Biedt DLNA niet praktisch dezelfde mogelijkheden :? Enkel is dat natuurlijk universeel....
DLNA is niet hetzelfde als bonjour en was er later ook.
SSDP is de tegenhanger van bonjour, maar ook dat is ontworpen voor kleine netwerken.

[Reactie gewijzigd door Dreamvoid op 9 november 2012 09:09]

Bonjour is ook een open systeem onder Apache licentie
Apple software voor Windows blijft altijd een ondergeschoven kindje en ik ben het met je eens dat dat eigenlijk meestal minder geweldig werkt (Safari voor Mac Windows is niet voor niets de nek om gedraaid). Hun focus is natuurlijk de Mac, en niet Windows. Dat jouw ervaring op windows met Bonjour slecht is wil natuurlijk niet zeggen dat Bonjour slecht is. Dat heeft meer te maken met de implementatie van Bonjour voor Windows die overigens niet meer is dan een Bonjour Print Services (dus slechts discovery van één service) en blijkbaar de rest van de ZeroConf iplementatie mist.

Dat je internet niet meer werkt na installatie van Bonjour Print Services lijkt me eerder op een fout in je Windows systeem duiden? Of was dat nog verder terug toen er volgens mij nog wèl Bonjour voor Windows bestond? Grote kans dat er een apparaat in je netwerk stond te broadcasten dat hij de router of DNS server was terwijl hij dat niet was?

Overigens zijn er vast ook wel andere ZeroConf clients voor Windows (Bonjour Print Services van Apple is er slechts één), zo vind ik bij een Google opdracht deze ZeroConf explorer, misschien heb je daar wat aan?

Dat je jeuk krijgt van Apple en standaarden in één zin is natuurlijk een beetje onzin. Het zou zomaar kunnen dat je zonder het te weten gebruik maakt van Apple technologie. Gebruik je Google Chrome? Dat is gebasseerd op de WebKit browser engine welke met name door Apple is ontwikkeld (ook al was het initieel een branch van khtml uit kde). Gebruik je *nix print servers? Dat gebruikt de open source Cups print daemon, wat is ontwikkeld door Apple. Gebruik je een GUI, muis en iconen? Hoewel dat in beginsel door XEROX PARC is bedacht is het door Apple doorontwikkeld en in de markt gezet....

[Reactie gewijzigd door 4np op 9 november 2012 14:57]

(Safari voor Mac is niet voor niets de nek om gedraaid)

Ik denk dat je Safari voor Windows bedoelde.
Oops! Aangepast, thanks ;)
Als er zoveel gebruik gemaakt wordt van het protocol vind ik het raar dat Apple daar nog niets aan heeft gedaan. Ik neem aan dat als je opmerkingen krijgt over je protocol dat het niet werkt in grote bedrijfsnetwerken en veel bedrijven willen en gebruik van maken, dat je daarvan wil profiteren.
Desalniettemin goed dat Apple er alsnog iets aan gaat doen. Het protocol is ook zeer gemakkelijk te gebruiken op thuisnetwerken met o.a. Apple tv's, bij Apple had ik dan ook wel verwacht dat ze dit zouden gaan gebruiken voor bedrijven, in potentie toch een gat in de markt als het goed uitgevoerd zal worden.
bonjour is geweldig, beetje jammer dat het op de support site gelabeled is als print driver voor windows.

Is echt super makkelijk in combinaties met zeroConf / mDNS op linux. Hoop dat ook de niuewe versie compatible blijft met dit soort systemen.

Op dhcp netwerken met dev servers is het essentieel om wat aan collega's te laten zien.
"Op dhcp netwerken met dev servers is het essentieel om wat aan collega's te laten zien" ???

Wegens een kennisgebrek van de persoon die wat wil laten zien waarschijnlijk, in essentie is het namelijk prima mogelijk om zonder dit protocol alles wat je wil aan de praat te krijgen.

Wel zal het misschien iets meer tijd / moeite kosten maar het blijft mogelijk.
Tuurlijk blijft het mogelijk, maar als je elke 2 dagen door de ruimte heen moet roepen wat je IP van die dag is. Wordt het kunnen bookmarken van piratelv-dev1.local/project op eens een stuk makkelijker.

Niet te praten over image resources.
Als DHCP en DNS goed geconfigureerd zijn heb je aan de hostname voldoende en is bonjour absoluut niet nodig. Sterker nog, zo is jarenlang gewerkt voor Bonjour bestond.
Bonjour klinkt als het zeeeeeer oude Protocol van Microsoft Windows, namelijk NetBIOS.
Lijkt of de geschiedenis zich aan het is herhalen.
Klinkt mischien hetzelfde maar is het niet.
Klinkt hetzelfde ja, er zit allebei een B en een O in de naam... 8)7

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! :O
Kunnen die apperaten hiernaast niet gewoon TCP/IP gebruiken?
Bekijk het OSI-model maar eens. Dit model legt uit hoe data wordt verstuurd over netwerken.

Bonjour is in dit geval een protocol wat over TCP/IP heen gaat :)
Bekijk het OSI-model maar eens. Dit model legt uit hoe data wordt verstuurd over netwerken.

Bonjour is in dit geval een protocol wat over TCP/IP heen gaat :)
Alleen jammer dat het OSI model zo slecht toepasbaar is op TCP/IP. OSI heeft 7 lagen, TCP/IP maar 4.

Kunnen we dat hele OSI model nu eindelijk eens gewoon naar z'n lieve fabeltjeswereld van ISOland verbannen, en ons concentreren op wat we in praktijk gebruiken?

(niet dat er geen netwerken zijn die niet daadwerkelijk OSI based protocollen gebruiken overigens, maar het merendeel van de wereld niet)
Dat kan wel, maar dan moet je zelf iets doen ;)

Ik snap eigenlijk niet goed waarom een admin van een groot netwerk zou willen dat een heleboel apparaten beginnen te broadcasten over het ganse netwerk. Het is knap voor thuisgebruik en misschien voor kleine bedrijfjes, maar op een groot netwerk zou ik toch via een printserver gaan.
Al die apparaten gebruiken TCP/IP. Maar dat is niet genoeg om elkaar te kunnen vinden in het netwerk, en om onderling uit te wisselen wat je kan.

Ter vergelijking een willekeurige chinees en ik gebruiken allebei spraak als communicatie medium (verg. TCP/IP). En als we naast elkaar staan, (verg. subnet) horen we elkaar ook nog. Maar dat betekend nog niet dat we elkaar begrijpen. Daarvoor zullen we toch eerst allebei moeten onderhandelen over welke taal we allebei spreken. Mogelijk komen we dan uit dat we allebei engels (verg. Bonjour) beheersen en kunnen we eindelijk onze informatie uitwisselen.
Kunnen die apperaten hiernaast niet gewoon TCP/IP gebruiken?
Dat doen ze ook.
Bonjour is een protocol waarmee netwerkapparaten elkaar snel kunnen vinden, zonder verdere configuratie.

[Reactie gewijzigd door edwingr op 9 november 2012 09:02]

Kunnen die apperaten hiernaast niet gewoon TCP/IP gebruiken?
Bonjour draait bovenop TCP/IP.

Bonjour zit ergens in de host layers van het OSI model, terwijl TCP en IP respectievelijk laag 4 en 3 zijn.
Als Bonjour in de "upper layers" van het osi model bevind. waar komt de limitatie dan vandaan dat het niet werkt tussen verschillende subnets? dit word geregeld door de network layer.

Kan je in die software geen ip invullen om een connectie maken? werkt het alleen met broadcast?

[Reactie gewijzigd door Eewokney op 9 november 2012 09:50]

Dat het in de hogere laag zit wil niet automatisch zeggen dat het ALLE features van de lagere lagen kan, of wil, gebruiken.

Bonjour gebruikt subnet-based broadcasts, en die, zoals subnet al aanduid, passeren normaliter geen routers die de koppeling tussen subnets regelen.
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.
Ik zeg nergens dat het een netwerk overbelast met multicast spam.

Het hele idee achter bonjour werkt prima, en is ook niet inherent onveilig. Het is zelfs prima in staat om IT medewerkers te ontlasten.

Het enige wat ik zei is dat het een ietwat luidruchtig protocol is, en dat slechte IDS achtige implementaties het daardoor ten onrechte blokkeren. (Ondanks herhaaldelijke klachten dat dat ongewenst gedrag is)
Bonjour is opgezet met kleine netwerken in het achterhoofd
Dus niet zo zeuren als je een groot netwerk hebt.

Bonjour is een heerlijke standaard welke ik dagelijks gebruik (streamen van audio, printers snel toevoegen, collega's snel in het netwerk vinden in Adium / Messages).
Maare waarom gebruiken ze niet de standaard van 2indows? Ik heb n9oit problemen met het vinden van apparatuur. Nas vind pc vind tv vind printer vind android telefoon
Probeer het eens uit, dan snap je dat het nog niet zo raar s dat ze het gebruiken. Voor een thuisnetwerk is het ideaal.
Tegen wie heb je het? :+
Helemaal mee eens, niet zeuren, gewoon alle Apple hardware geen toegang tot je netwerk verlenen als je een groter netwerk hebt.

Denk dat veel mensen dan bij je komen klagen als je op de ICT afdeling werkt. Het probleem is natuurlijk dat mensen een Apple product hebben en verwachten dat het werkt zonder door te hebben hoeveel kopzorgen dit geeft voor de beheerders. En al die mensen boeit het echt niet dat bonjour niet bedoeld is voor grote netwerken, het moet werken en anders worden ze boos.

Ik snap heel goed dat mensen zijn gaan vragen of het opgelost kan worden, andere optie zou zijn alle apple hardware niet toestaan op het netwerk.
Iphone kan prima veilig zijn in bedrijfsnetwerk
http://help.apple.com/ios.../1.0/?lang=nl#appc28ee0f4
Apple devices werken perfect op netwerken waar bonjour geblokkeerd is.

Daar voor hoef je ze echt niet voor de toegang compleet te ontzeggen.
"Dus niet zo zueren als je een groot netwerk hebt."
Wat is dat nu weer voor argument? Er werd toch ook niet direct gezeurd, maar er werd een petitie opgezet met de vraag om de functionaliteit uit te breiden om ook grotere netwerken te ondersteuen. Dat Apple hier vervolgens gehoor aan geeft is zeer positief!

edit: Was als reactie op Neus bedoeld.

[Reactie gewijzigd door Kawaii op 9 november 2012 09:05]

Ook een klein netwerk kan meerdere subnets hebben, denk aan je apparaat van je provider en eigen access point. Of een 2e access point voor beter bereik.
Gewoon je netwerk "extenden" door twee routers aan te sluiten waarvan je bij 1 gewoon dhcp uit zet en die via de "LAN" kant aansluit op de andere. Heb je gewoon maar 1 subnet en loop je niet te klooien.
Als je dat hebt om die reden ben je als beheerder incompetent.
Dat betekend dus dat wij als netwerk-beheerders deze rommel gewoon mogen weren van het netwerk, Daar ben ik het helemaal mee eens, echter ben ik bang dat ik dan heel veel commentaar krijg van al de apple-fanboys dat hun speelgoed niet meer werkt |:(
scn
vrijdag 9 november 2012 09:15
Dat betekend dus dat wij als netwerk-beheerders deze rommel gewoon mogen weren van het netwerk, Daar ben ik het helemaal mee eens, echter ben ik bang dat ik dan heel veel commentaar krijg van al de apple-fanboys dat hun speelgoed niet meer werkt |:(
Waarom nou weer zo'n sneer naar Apple gebruikers door de fanboys te noemen?
Is dat nou echt altijd nodig? Kansloos gedrag.

[Reactie gewijzigd door Typecast-L op 9 november 2012 13:06]

Fanboy of niet, dat staat er los van.
Het gaat erom dat de gebruiker geen last wil ervaren van enigerlei technische beperking.
De beheerders willen geen last van netwerkstoringen en beveiligingsissues.
Die twee gaan niet perfect samen. Dat is wat zo nu en dan botst.
Wat een karikaturale reactie :D

Typisch een beheerder die niet snapt dat netwerken en computers geen doel op zich zijn maar bestaan zodat gebruikers hun werk goed kunnen doen.

Als ze apple (of ander merk) spullen fijn vinden werken en hun werk daardoor beter/sneller/efficienter/weet ik veel kunnen doen dan kan je beter naar een goede oplossing om dat mogelijk te maken zoeken in plaats van meteen "rommel" en "van het netwerk weren!" en "fanboys" te roepen.

Daarnaast gaat Apple deze standaard aanpassen zodat hun spul beter werkt met grote netwerken, hardstikke mooi toch?
Zijn het niet de gebruikers die moord en brand schreeuwen als het netwerk/server/service/tool eruit ligt omdat er weer een onbekend apparaat aan het netwerk gekoppeld is die niet beheerd is en waarop een virus/trojan stond?

Zijn dat niet dezelfde gebruikers die moord en brand schreeuwen als hun eigen device niet op het netwerk toegelaten wordt?

Ziehier het probleem van beheerders. Ze moeten de IT beheren, niet mogelijkheden bieden het kapot te maken. Niet de mogelijkheid bieden om de uptime van de services naar beneden te halen.

IT biedt de gebruikers deze mogelijkheid. En ja, het zou mooi zijn als dat met eigen devices zou kunnen, maar er is ook nog zoiets als security. Bedrijfsdata mag vaak niet op onbeveiligde devices geplaatst worden. Eigen devices zijn vaak niet beveiligd en bevatten te vaak trojans en andere vuile software waardoor bedrijfsinformatie doorgespeeld wordt naar concurrenten.

Daarom is bring your own device vaak niet mogelijk. Begrepen die gebruikers dat maar eens...
Sorry maar als beheerder zelf kan ik me niet in je verhaal vinden. Uiteraard mag er geen bedrijfsdata staan op onbeheerde devices maar BYOD is prima mogelijk te maken via Citrix XenApp, goede firewalling en VLANs.

Ook al komen ze met een iPad binnen. Client erop en draaien maar. Als je wilt gooi je er nog een Token oplossing overeen (zoals je bij je telebankieren doet).

Die gebruikers zullen dat nooit begrijpen. Dat komt omdat ze gebruikers zijn. Jij bent de persoon waar ze heen gaan voor begrip en jij moet oplossing voor hun verzinnen.

[Reactie gewijzigd door dycell op 9 november 2012 23:40]

Het is geen "Breng Je Own Device" maar het is BYOD Bring Your Own Device.
Typisch een systeembeheerders-stuip die je altijd zal vertellen waarom iets niet kan of niet zal werken.
En ook weer een reactie van een typische gebruiker die wel meer mogelijkheden wil, maar er niet voor wil betalen.
En wat als de vertrouwenlijke data in eens op Internet verschijnt? Wie is er dan de schuldige?

ICT wil alles aanbieden, maar het moet wel goed werken. Anders krijgt ICT weer klachten en boze gebruikers. Maar alles aanbieden kost geld.
Typische gebruikers reactie .... In een coorperate omgeving wil je standaards en niet alles wat eventueel mogelijk is. Het is geen thuis netwerkt/omgeving dus argumenten dat het zo lekker werkt gaan absoluut niet op.
Typische gebruikers reactie .... In een coorperate omgeving wil je standaards en niet alles wat eventueel mogelijk is. Het is geen thuis netwerkt/omgeving dus argumenten dat het zo lekker werkt gaan absoluut niet op.
Fout het is jouw argument wat niet opgaat. De baan van de beheerder is juist om te zorgen dat zelfs op grote schaal alles vlekkeloos en "lekker" werkt. Daar wordt je voor betaald. Niet om allemaal regels op te leggen etc.

Ja standaarden zijn handig en je kunt ervoor kiezen om alleen bepaalde standaarden te gebruiken maar daar zorg je alleen maar mee voor onvrede en productiviteitsverlies. En dat is nou juist waarvoor jij betaald wordt om op te lossen. Zo veel mogelijk standaarden accepteren is altijd wijs.

Een gebruiker wil graag met een iPad via AirPlay een presentatie geven? Geen probleem, dat regelt de beheerder. Beheerders moeten niet bij enigszins moeilijke/uitdagende opdrachten direct moeilijk gaan doen met het argument "het kan niet" of "ik weer die rommel" of "je bent maar een fanboy".

[Reactie gewijzigd door Denni op 9 november 2012 12:34]

maar daar zorg je alleen maar mee voor onvrede en productiviteitsverlies. En dat is nou juist waarvoor jij betaald wordt om op te lossen.
Daar wordt een systeembeheerder niet voor betaald, een systeembeheerder wordt betaald om (ICT) beleid uit te voeren.
Een systeembeheerder wordt over het algemeen (te weinig) betaald om:
  • Management beleid uit te voeren betreffende ICT;
  • Systemen en ondersteunende componenten draaiende te houden, liefst pro-actief;
  • Te helpen bij advies voor nieuwe diensten;
  • Gebruikers het beste te bieden wat binnen het beleid valt;
  • Stabiliteit te creeren binnen de iCT omgeving;
  • Klappen te krijgen van gebruikers omdat ze iets niet mogen omdat het beleid zo is;
  • Als boksbal te dienen voor gebruikers en mensen met hobby projecten die denken dat ze het beter weten omdat ze thuis toevallig ook een netwerk hebben;
  • Het pispaaltje zijn.
Speeltjes van gebruikers druisen tegen alles in wat een systeembeheerder doet en mag doen. Wanneer er geen standaarden zijn binnen een bedrijfsnetwerk kan een beheerder nooit stabiliteit garanderen en is deze altijd de pineut als er iets om valt omdat een "cowboy" weer wat op eigen initiatief in het netwerk heeft gehangen.

Een systeembeheerder kan adviseren bij ontsluiting van technologie, maar moet er ook niet voor gaan liggen of bepalen met welke tools er gewerkt wordt. Maar management moet wel beseffen dat "die ene tool" misschien minder verstandig is dan "die andere tool" en gebruikers moeten zich daar bij neerleggen. En wanneer je ziet hoe veel ellende en kosten er gemaakt worden omdat "hobbybob" in 2000 een paradox databaseje heeft geschreven waardoor nu complete migratie trajecten problemen ondervinden, dan moet men beseffen dat "een tool", hard- en/of software moet passen binnen een bepaald beleid en dat byos (Bring Your Own Shit) niet altijd gepast is.
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.
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?).
Het zijn inderdaad niet de systeembeheerders die moeten bepalen welke tools er gebruikt worden, maar het is ook niet aan de gebruikers om dat te bepalen.
Die taak ligt bij het management, en daar zijn systeembeheerders een uitvoerende tak van.
Dus ja, als het management zegt dat alleen schroevendraaiers ondersteunt worden dan kun je het dak op met je hamer.
Apple-fanboys? Speelgoed? Als een consultant met zijn iPad graag draadloos wil presenteren met een Apple-TV, dan heb je daar toch echt Bonjour voor nodig. Vergeet niet dat die consultant het geld binnenharkt waar jouw salaris van betaald wordt.
cAls een consultant met zijn iPad graag draadloos wil presenteren met een Apple-TV
Die consultant geeft 9 van de 10 keer presentaties op locatie bij een klant, en krijgt dus te maken met systeembeheer daar. Over het algemeen kost het alleen maar geld als die jongens bij je langs komen.
. Vergeet niet dat die consultant het geld binnenharkt waar jouw salaris van betaald wordt.
Die consultant verkoopt wat ik bouw. Met andere woorden: hij kan niet zonder mij, en ik kan niet zonder hem. De een is niet meer dan de ander.

En ik GUN hem dat z'n apperatuur goed werkt. Da's ook mijn apperatuur namelijk.

En als we dan toch bezig zijn: de geldige reden waarom veel IT clubs momenteel bonjour (ook wel bekend als zeroconf) weigeren/blokkeren is omdat het een verdraaid luidruchtig protocol is. Een aantal consumenten kabel/dsl modems/routers blokkeren het protocol daarom ook vaak na een paar minuten, het lijkt namelijk op een soort (D)DoS multicast aanval.

Als ze dat met de nieuwe draft ook enigzinds binnen de perken weten te houden, wordt dat erg leuk.

Ik vraag me af of bonjour dan ook weer gaat werken als ik bijvoorbeeld met m'n iPhone of iPad naar m'n thuisnetwerk VPN. (L2TP)
De vraag is, wil je die bonjour ellende in je netwerk ;)
De vraag is, wil je die bonjour ellende in je netwerk ;)
Ja. Het geeft een aantal voordelen waar ik als techneut toch echt niet omheen kan.

Het is - zoals ik al zei - een ietwat luidruchtig protocol. Maar dat is slechts 1 nadeel tegenover een fors aantal voordelen. Zeroconf - de opensource implementatie van bonjour, wordt niet voor niets standaard meegeleverd bij o.a. redhat.
En de consultant pas wat kan doen als de enigineer iets goeds neer zet dus eigenlijk zorgt de enigneer voor het geld en hoeft de consultant slechts wat te presenteren. Zonder goed product kan hij namelijk ook niets en is hij nutteloos.

(sorry maar ik word heel moe van deze opmerkingen dat sales/consultants het geld verdienen)
Zo een consultant kan dan netjes een "hubje" krijgen waarop ie zelf zijn 2 devices mag aansluiten zonder ellende te veroorzaken in het netwerk.

Als je een beetje goed 4-tier model hebt opgezet binnen je netwerk dan hoeft dat zelfs niet maar moeten ze ook niet klagen :-)

Overigens, niets staat deze "consultant" in de weg om een kabeltje te gebruiken tussen zijn 2 devices, 1gbps ethernet heeft tenslotte geen cross nodig :P

[Reactie gewijzigd door Wim-Bart op 10 november 2012 00:31]

Hier moet ik dan weer op reageren.
Je stelt nu alle IT gelijk. Maar het gaat hier over IT infrastructuur. En daar wordt heel zelden het geld verdient.
Je kunt er wel moe van worden, maar het is zo.

Een goede consultant/adviseur/verkoper zeurt niet over het feit dat hij een dienst verleent, maar doet dat graag. Jammer dat sommige techneuten zich niet denstbaar op kunnen stellen en denken dat de wereld om hen draait, of dat ze onmisbaar zijn. Je bent pas onmisbaar wanneer je de enige bent die een product/dienst kan leveren en wanneer het tevens een product/dienst is waar je (interne) klant niet buiten kan.

Hier heeft sales ook mee te maken, enkel even een presentatie geven, daarmee red je het niet.

Als je dan zo moe wordt en moeite hebt met een dienstverlenende instelling, kun je beter ambtenaar worden of uitkeringstrekker.Een salesfunctie zou ook niet aan jou besteed zijn.
Je zou binnen een organisatie er ook voor kunnen kiezen gewoon een Android apparaat te kopen en deze draadloos laten streamen naar een willekeurige kastje of gewoon via een HDMI wifi adapter achtige constructie.
Het gaat erom dat de baas van de consultant bepaald waar de consultant mee mag spelen, niet andersom.

Als laatste wil ik even kwijt dat Apple nu herkent dat bonjour beperkingen heeft! Waarom is hier niet eerder aan gedacht. "Apple producten werken toch altijd en overal met elkaar." Nou blijkbaar alleen wanneer het binnen de beperkingen ligt waarvoor Apple kiest. (onder het mom van: doe het meteen goed)
Wat probeer je nou te zeggen? Volgens jou is alles dus perfect en zijn gebreken dommigheid en zelfs opzet van Apple? Bonjour gaat al wat jaartjes mee en de IT wereld en het gebruik verandert en dus moet je het mee veranderen.
En ja het werkt overal met elkaar, maar elk product heeft zijn beperkingen.

Of heeft je Android voorstel dan geen beperkingen? Ik vrees het ergste voor jou
Als laatste wil ik even kwijt dat Apple nu herkent dat bonjour beperkingen heeft!
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.

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.
Inderdaad, het ewige gezeur tussen technisch goed en de user met toys.
Is gewoon hetzelfde als het ewige gezeur tussen gebruiksgemak en security...

Reden voor dit alles: Een kennisgebrek bij de gebruiker...

Probleem wat ik vervolgens wel tegen kom, hoe goed je het ook uit probeert te leggen aan gebruikers de verslaving aan de toys is ondertussen zo groot dat het lijkt alsof je tegen een in de goot liggende zwerver staat uit te leggen dat ie die spuit beter niet in z'n arm kan zetten.

Met andere woorden het interreseert ze geen moer als ze hun speeltje maar kunnen gebruiken.
Tja, wat zal ik zeggen. Een duidelijke reactie van een niet klantgerichte beheerder zou ik bijna zeggen.
Wij van de "IT-afdeling" bepalen wel even wat de klant maar goed moet vinden.
Wie denk je wie uiteindelijk de rekening moet betalen? Dat is toch echt de gebruiker/klant, niet de IT afdeling.

Zo werkt het toch echt niet in de grote mensen wereld. IT is nog altijd een middel om zaken te kunnen doen. Het is niet de core business van de meeste bedrijven. Het is aan de IT afdeling om te zorgen dat de klant krijgt wat hij wil, binnen bepaalde grenzen, dat dan weer wel.

Sorry, moest ik ff kwijt.
als de organisatie aangeeft dat dit soort apparatten moeten worden ondersteund dan heb je gelijk. Dan is er een business plan gemaakt waarin de kosten en winsten van het gebruik van zulke 'toys' bewezen wordt. Er wordt ook gekeken naar andere niet onbelangrijke aspecten zoals beveiliging van bedrijfsdata, extern beheer (out-of-band management), backups, toegestane applicaties etc.

Wat je vaak ziet is dat van zo'n opzet geen sprake is. Men koopt wat en het moet nu werken. Dan krijg je verzet, inderdaad. Uiteindelijk zijn de mensen van de it afdeling verantwoordelijk voor het geheel en als dossiers op straat komen te liggen en de data van jouw organisatie op en niet positieve manier de regionale/nationale pers haalt, dan zijn ze vaak de pineut.
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?
Het zelfde met de vervuiling , de gewone mens vraagt er niet om
Totdat je niets meer met vergiftigde rivieren en grond kan
Dan nadenken waar het werkelijke probleem ligt
Dus geen ivorentoren van de techneut maar van degene die voor 5ct
een miljoen wil verdienen
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.
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.
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.
Je bent in de war met het oude "chatty" AppleTalk over Ethernet protocol.

Zelfs op grote netwerken met honderden Mac's is Bonjour/ZeroConf geen enkel probleem.
Precies, wat velen vergeten maar wel de realiteit is dat zaken van best lang goed gaan tot er een bepaalde kritische grens wordt berijkt. Dan wordt het niet steeds langzamer maar komen zaken ineens heel abrupt tot stilstand.

En dan staat ineens iedereen zich af te vragen hoe dat nou kan...

In een grote omgeving zijn dit soort protocollen wat mij betreft een "bad practise" en zouden zolang ze niet verbeteren verbannen moeten worden.

Ik vraag mij dan ook af wat er straks gaat gebeuren, ik maak nu nog handig gebruik van het feit dat broadcast niet gerouteerd wordt dus we hebben die appelige apparaten gewoon lekker in een appart VLAN gestopt.

Ik vraag me dan ook af hoe een multisubnet versie van bonjour er uit gaat zien, en hou mijn hart vast...
Hopelijk sluiten ze aan bij Microsofts Peer Name Resolving Protocol.
(Wat Vista en later gebruiken.)
Dit is al voor een flink deel compatible met de huidige Bonjour en ondersteund ook IPv6.
(Sterker nog, het is met name voor IPv6 bedoelt.)

Voeg er een paar extensies voor OSX/iOS aan toe en je bent er in principe al.
Wat denk jij dat goedkoper is: Elke gebruiker op je netwerk moet bij de systeembeheerder langs om de printer in te stellen en/of moet een handleiding raadplegen voordat hij of zij kan printen. Of hij drukt gewoon op 'print' en het werkt direct?

Dit soort zaken kan een bedrijf duizendend euro's kosten. Hardware is goedkoop, mensen zijn dat niet.
Een netwerk dat een klein beetje beheert wordt, rolt zijn printers uit via het logonscript, dat de gebruiker helemaal niks hoeft te doen, buiten op print te klikken
Ga weg met je loginscripts... dat is zo NT4...

Een beetje beheerder heeft zijn GPP's ingericht die er voor zorgt dat gebruikers automatisch de printer krijgen die het dichtste bij is...
Was bonjour nou niet bedoeld om dat niet te hoeven?
Wij hebben op het werk 'follow me'. Dat houdt in dat de printopdracht de cloud ingaat, en er weer uitkomt daar waar je met je smartcard inlogt.
Ja, maar dat is dus Conf en geen ZeroConf... Bonjour is ZeroConf, een set protocollen die je in staat stelt enerzijds een netwerk zonder configuratie op te zetten en anderzijds services en devices te laten discoveren. Daarnaast is er ook méér op je netwerk dan alleen een printer in een login script...
Ja, maar dat is dus Conf en geen ZeroConf... Bonjour is ZeroConf, een set protocollen die je in staat stelt enerzijds een netwerk zonder configuratie op te zetten en anderzijds services en devices te laten discoveren. Daarnaast is er ook méér op je netwerk dan alleen een printer in een login script...
Mooi, bedrijf met 400 vestigingen (ik ken ze met meer), 2 printers per vestiging. En dan kom je met je mac. even bonjour over het wan heen. Joepie ik kan printen, op 800 printers. Kut, waarom is mijn mac zo traag, o ja, hij staat 4 uur lang alle printer instellingen op te halen.

Ja, na 4 uur heb ik een printer, nu even alle 400 vestigingen afbellen waar mijn print ligt :P
Ach als het echt efficient moet weer je ook TCP en IP inefficiente jaren 70 houtje touwtje protocollen niet gebruiken. Weet je wat, schakel gewoon de switch uit, helemaal geen inefficient verkeer meer. Wat ik bedoel te zeggen is: als je die bandbreedte hebt, gebruik die dan ook voor gebruiks gemak. Hoeveel procent belasting zorgt het nou eigenlijk? Als je een sterk versplintert netwerk heb met subnetten is dat het toch niet kan werken een goede reden het uit te schakelen, Maar een beetje traffic, daar dient het netwerk toch voor?
Die bandbreedte is maar 1 zaak (die trouwens geld kost), maar al je pc's, kortom alles wat een netwerkkaart heeft in je netwerk ontvangt die broadcasts, en moet die ook tot op laag 3 verwerken, om te zien of die broadcast voor hun is of niet, dit vraagt werk van je netwerkkaart en van de processor van je pc.
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).

Voor de huis tuin en keuken gebruiker is bonjour ideaal, maar op een deftig netwerk wil je dergelijke protocols helemaal niet.
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).
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.

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.
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.

[Reactie gewijzigd door johnbetonschaar op 9 november 2012 10:23]

Het zou me niks verbazen als Microsoft gewoon standaard een 1-op-1 equivalent van Bonjour heeft draaien op elke Windows computer.
Nee.
windows heeft zijn equivalent van bonjour, netbios (over tcp/ip).

en je redenering van die 0,0001% slaat nergens op, als een pc al plat krijgt, door er genoeg ping's om maar een duidelijk vb te geven naar toe te sturen, hangt het gewoon af van de hoeveelheid verkeer, die door die netwerkkaarten moet verwerkt worden, een netwerk met 200 printers die allemaal staan te broadcasten met bonjour, een arp stompje hier, en daar nog wat broadcast door netbios... excessive broadcasts maken je netwerk en je pc's traag, iedere broadcast die je kan vermijden, zet je best uit. En bonjour kan je vermijden, je hebt het voor niks nodig
windows heeft zijn equivalent van bonjour, netbios (over tcp/ip).
en we hebben in de Windows wereld net met veel moeite die netBIOS broadcasts grotendeels eruit gekregen... krijgen we deze ellende weer.
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.

[Reactie gewijzigd door johnbetonschaar op 9 november 2012 11:09]

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.
Dt kan ik bevestigen. As ik wel eens zit te sniffen op 1 van m'n servers thuis zie ik geregeld wat verkeer voorbij denderen van de Airports, AirPlay devices, printer, werkstations (allemaal Apple). Maar om nou te zeggen dat ik daar compleet de rest van het verkeer niet meer door kan zien? Nee. Het is best een luidruchtig protocol, maar meer dan 1MB per 24 uur trekt het niet volgens mij.
Ik heb twee jaar geleden in mijn huis een domotica systeem geïnstalleerd van Wago (750-860). Hierop draait uClinux. In het begin draaide dit goed, maar na verloop van tijd liep de kernel 's avonds regelmatig vast.
Na lang zoeken bleek het een probleem te zijn met de ip stack van uClinux. De ip stack kreeg een overvloed aan packets waardoor de kernel in een soort van dead lock terecht kwam. Toen verder gezocht en bleek dat de problemen veroorzaakt werden door iTunes die ik had geïnstalleerd. De problemen verdwenen toen ik iTunes niet meer uitvoerde. Gelukkig kwam er een patch beschikbaar voor uClinux.
Maar het bonjour protocol is wel degelijk de oorzaak voor m'n netwerk problemen thuis.
Ik heb twee jaar geleden in mijn huis een domotica systeem geïnstalleerd van Wago (750-860). [...] De problemen verdwenen toen ik iTunes niet meer uitvoerde. [...] Maar het bonjour protocol is wel degelijk de oorzaak voor m'n netwerk problemen thuis.
Dat is zoiets als zeggen "Als ik mijn voordeur open doe dan stort het huis in, sinds ik mijn voordeur dichtgemetseld heb en altijd de achterdeur gebruik verdween dat probleem. Maar de voordeur was wel degelijk de oorzaak voor m'n huisproblemen."

Als je Wago domoticasysteem crasht van wat bonjour broadcasts, dan is een bug in je Wago systeem de oorzaak van je problemen, niet bonjour. Je kunt bonjour nog steeds slecht en nutteloos vinden, maar was niet de schuldige partij in je probleem ;)
Na lang zoeken bleek het een probleem te zijn met de ip stack van uClinux.
[..]
Gelukkig kwam er een patch beschikbaar voor uClinux.
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:
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... ;) :P
Het klinkt alsof uClinux er een probleem van maakte. Maar waarom moet uClinux het (potentiële) probleem oplossen van een bepaald protocol?
Beide fabrikanten zouden hun zaakjes op orde moeten hebben!
Omdat hierboven nogal veel reacties staan die kant nog wal raken, even een korte uitleg.

Bonjour is Apple's implementatie van Zero configuration networking (ZeroConf) en heette oorspronkelijk Rendezvous (totdat het in 2005 ivm legal dispute over de naam moest worden veranderd). ZeroConf is een set tools/protocollen die het mogelijk maken om zonder configuratie andere devices (computers, printers, servers) op je netwerk te zien, én om services op die devices te kunnen zien (Apple Talk, SMB, web server, ssh, iTunes/DAAP, etcetera) en dus snel te kunnen openen. Het bestaat met name uit DNS-Based Service Discovery (DNS-SD) en Multicast DNS (mDNS) en biedt het in feite de toegevoegde mogelijkheid om zónder configuratie een IP netwerk te gebruiken, héél gebruiksvriendelijk maar de horror van elke BOFH ;)

Met name Apple gebruikt ZeroConf, en dat is natuurlijk niet gek omdat Usability en gebruiksvriendelijkheid hoog in 't vaandel staan bij Apple. Als je wel eens een Mac hebt gebruikt, dan zie je computers en printers in de Finder verschijnen of verdwijnen zodra ze respectievelijk aan of uit worden gezet. Zo hoef je in feite als gebruiker niets te doen want alle andere devices op het netwerk zijn gewoon beschikbaar (mits ze ook Bonjour / ZeroConf gebruiken). Maar, zoals de auteur ook beschrijft, dit werkt alleen in één netwerk en niet over subnetten. Dat kan nogal een gemis zijn, óók in de wat geavanceerdere thuis situaties (denk aan WiFi op een ander subnet, vpn connecties, etcetera).

Er is ook een implementatie voor Linux: Avahi, wat je in staat stelt om services op je Linux server te broadcasten en dus te laten discoveren door Bonjour / ZeroConf gebruikers. Zo kan je bijvoorbeeld mt-daapd / Firefly Media Server (DAAP is het iTunes protocol) in combinatie met Avahi gebruiken op je Linux server met veel storage om een media bibliotheek op te zetten die via het netwerk gevonden kan worden, én in iTunes zichtbaar is als gedeelde muziek bibliotheek (en dus te streamen). mt-daapd implementeerde vroeger zelf mDNS en ik weet niet of Firefly dat ook nog steeds doet (al jaren niet meer gebruikt), maar je kan het in ieder geval uit zetten en Avahi de Bonjour taken laten waarnemen.

En voor werk situaties kan het handig zijn om test, development en continuous integration -servers te broadcasten, als ze tenminste niet (zoals de meeste grotere bedrijven) ergens in een ander subnet / colo staan :)

In ieder geval zou een nieuwe standaard die over subnetten werkt (vanuit gebruikers oogpunt) een welkome uitbreiding zijn zodat je ook servers, computers, printers etcetera kan discoveren die zich op andere subnetten of zelfs over vpn bevinden :) Al kan ik me voorstellen dat hoe groter het netwerk is, hoe meer netwerk vervuiling op kan gaan treden als alle Bonjour devices blijven broadcasten. Wellicht dat bij de revisie van de standaard ook deze potentiële toegenomen vervuiling is meegenomen.

ps. een quote van de introduction van het voorstel van de mdnsext standaard voor de mensen die niet op het linkje hebben geklikt:
The DNS-SD/mDNS Extensions Working Group (MDNSEXT) will develop
extensions to DNS-Based Service Discovery [DNS-SD] and Multicast DNS
[mDNS] protocols to enable service discovery beyond the local link.

DNS-SD/mDNS is widely used today for discovery and resolution of
services and names on a local link. In principle DNS-SD can also be
used in conjunction with conventional unicast DNS to enable wide-area
service discovery, but in practice this capability is not widely
used. This disconnect between customer needs and current practice
has led to calls for improvement, such as the Educause petition [EP].

In response to this and similar evidence of market demand, several
companies have recently announced "Bonjour gateway" products that
allow service discovery beyond the local link. However, these were
brought to market rapidly and it's unclear whether they represent the
best long-term direction for service discovery protocol development.

Similarly, DNS-SD/mDNS in its present form is not well suited for
emerging technologies such as multi-link subnets like 6LoWPAN where
"link local" is defined as a node's first-hop neighbors, subnet-
scoped multicast is problematic, and battery powered devices may be
offline for significant periods of time.

For these and other reasons, it is therefore beneficial for end
users, network operators, vendors, and for the long-term health of
the Internet to bring this work into the IETF where all interested
parties can cooperate to develop efficient and scalable solutions.

This document defines the problem statement and gathers requirements
for DNS-SD/mDNS Extensions.

[Reactie gewijzigd door 4np op 9 november 2012 11:18]

Een interessante post, bedankt voor je uitleg. :)
Al kan ik me voorstellen dat hoe groter het netwerk is, hoe meer netwerk vervuiling op kan gaan treden als alle Bonjour devices blijven broadcasten
En ziedaar de reden waarom je dit in enterprise networking niet wil.


Maar goed, het is wel makkelijker om je CIO de rekening te sturen van de 10GB uplink - dat doe je dan gewoon met een gedeeld documentje wat ie via Bonjour kan zien, en dan geef je als motivatie op dat Bobnjour anders niet goed werkt :P
Lol :) Maar zo te zien denken ze er in ieder geval over na bij de mdnsext standaard:
REQ03: Scalability, in terms of:
- Network traffic
- CPU and memory requirements on network entities
- User interface (huge flat list is not user friendly)
- Having a smooth continuum of operation from local link to site to
global, rather than vastly different incompatible modes of
operation at different network scales
- Granularity of services available on a server (extend the notion of
service?)

Op dit item kan niet meer gereageerd worden.



LG G4 Battlefield Hardline Samsung Galaxy S6 Edge Microsoft Windows 10 Samsung Galaxy S6 HTC One (M9) Grand Theft Auto V Apple iPad Air 2

© 1998 - 2015 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True