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)
"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.
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 vrijdag 9 november 2012 09:05]
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?
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.
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.
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.
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.
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)
(sorry maar ik word heel moe van deze opmerkingen dat sales/consultants het geld verdienen)
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.
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.
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 stelt nu alle IT gelijk. Maar het gaat hier over IT infrastructuur. En daar wordt heel zelden het geld verdient.
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
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
[Reactie gewijzigd door Wim-Bart op zaterdag 10 november 2012 00:31]
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
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
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.
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.cAls een consultant met zijn iPad graag draadloos wil presenteren met een Apple-TV
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.. Vergeet niet dat die consultant het geld binnenharkt waar jouw salaris van betaald wordt.
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 
Ja. Het geeft een aantal voordelen waar ik als techneut toch echt niet omheen kan.De vraag is, wil je die bonjour ellende in je netwerk
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.
Wat een karikaturale reactie 
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?
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...
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.
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 vrijdag 9 november 2012 23:40]
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.
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.
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 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.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?).
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.
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.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.
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 vrijdag 9 november 2012 12:34]
Daar wordt een systeembeheerder niet voor betaald, een systeembeheerder wordt betaald om (ICT) beleid uit te voeren.maar daar zorg je alleen maar mee voor onvrede en productiviteitsverlies. En dat is nou juist waarvoor jij betaald wordt om op te lossen.
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.
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.
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.
Als je dat hebt om die reden ben je als beheerder incompetent.
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.
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.
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.
Dat doen ze ook.Kunnen die apperaten hiernaast niet gewoon TCP/IP gebruiken?
Bonjour is een protocol waarmee netwerkapparaten elkaar snel kunnen vinden, zonder verdere configuratie.
[Reactie gewijzigd door edwingr op vrijdag 9 november 2012 09:02]
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.
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.
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.
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.
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
Bonjour is in dit geval een protocol wat over TCP/IP heen gaat
Bonjour draait bovenop TCP/IP.Kunnen die apperaten hiernaast niet gewoon TCP/IP gebruiken?
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?
Kan je in die software geen ip invullen om een connectie maken? werkt het alleen met broadcast?
[Reactie gewijzigd door Eewokney op vrijdag 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.
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)
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)
Nee, sorry. Bonjour heeft behalve dat het ook met computernetwerken te maken heeft, verder helemaal niks met WOL te doen
Bonjour is tevens wat je zegt tegen elkaar als je net wakker wordt in Frankrijk... wakker worden als je geroepen wordt is de leken uitleg van WOL, dus dat is nog een link die WOL met Bonjour heeft... 
anders dan dat heeft het niks met WOL te maken inderdaad :-)
anders dan dat heeft het niks met WOL te maken inderdaad :-)
Haha, grapjas, ik heb net ff wikipedia bekeken en eigenlijk is mijn opmerking +1.
Kijk vooral even naar de laatste zin... ;-)
Kijk vooral even naar de laatste zin... ;-)
Wake-on-LAN (WOL) is an ethernet computer networking standard that allows a computer to be turned on or woken up by a network message.
The message is usually sent by a program executed on another computer on the same local area network. It is also possible to initiate the message from another network by using subnet directed broadcasts or a WOL gateway service. Equivalent terms include wake on WAN, remote wake-up, power on by LAN, power up by LAN, resume by LAN, resume on LAN and wake up on LAN. In case the computer being woken is communicating via Wi-Fi, a supplementary standard called Wake on Wireless LAN (WoWLAN) must be employed.[1]
The WOL and WoWLAN standards are often supplemented by vendors to provide protocol-transparent on-demand services, for example in the Apple Bonjour wake-on-demand (Sleep Proxy) feature.[2]
DLNA is niet hetzelfde als bonjour en was er later ook.Biedt DLNA niet praktisch dezelfde mogelijkhedenEnkel is dat natuurlijk universeel....
SSDP is de tegenhanger van bonjour, maar ook dat is ontworpen voor kleine netwerken.
[Reactie gewijzigd door Dreamvoid op vrijdag 9 november 2012 09:09]
Bonjour is ook een open systeem onder Apache licentie
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 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.
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.
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.
Niet te praten over image resources.
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.
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).
Voor de huis tuin en keuken gebruiker is bonjour ideaal, maar op een deftig netwerk wil je dergelijke protocols helemaal 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.
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]
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
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
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]
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.
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.
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...
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."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.
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
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.
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.
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
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...
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...
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 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.
Je bent in de war met het oude "chatty" AppleTalk over Ethernet protocol.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.
Zelfs op grote netwerken met honderden Mac's is Bonjour/ZeroConf geen enkel probleem.
Nooit met een Apple over port 9100 geprint? Probleem opgelost toch.
Als ik verbinding maak met jouw netwerk (draadloos of bedraad), kan ik dan met twee klikjes een printopdracht naar de printer sturen of video/presentatie/website op een AppleTV weergeven, zonder iets te configureren en zonder voorkennis te hebben?
Dat is immers de kracht van Bonjour.
Verder gebruikt Apple Micro USB niet vanwege de beperkingen. Daar is een goede reden voor.
Dat is immers de kracht van Bonjour.
Verder gebruikt Apple Micro USB niet vanwege de beperkingen. Daar is een goede reden voor.
Printermanagement? Bonjour op je printserver, opgelost. Bovendien maak je dan je printers toegankelijk die geen bonjour/airprint ondersteunen.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 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
