Servers vinden op lokale netwerk

[Xudonax]

Mijn vraag
Ik heb 1~45 servers, en wil deze automatisch detecteren. Verdere communicatie is allemaal naar één specifieke server. Wat is hier de beste manier voor, een multicast groep waar ik maar enkele pakketten naar stuur of een broadcast sturen en op die manier alle servers detecteren?

Het netwerk is sowieso een afgesloten geheel, er gaat niets anders op zitten dan een controller en 1~45 servers. Het is dus niet heel belangrijk om rekening te houden met overige devices op het netwerk.

Relevante software en hardware die ik gebruik
De servers zelf wil ik schrijven in C/C++ en draaien op een Raspberry Pi of iets soortgelijks, de client welke het detecteren moet gaan doen wil ik bij voorkeur in Java maken vanwege de platform onafhankelijkheid.

Wat ik al gevonden of geprobeerd heb
Omstreeks 2004 heb ik dit vaker gedaan in Visual Basic 6, maar hier heb ik voor zover ik weet altijd een broadcast gestuurd. Het doel is enkel om de andere machines te detecteren, en te detecteren wat hun mogelijkheden zijn (ze kunnen I²C, SPI en/of WS2812 LED strips aanbieden).

De communicatie welke ik nodig denk te hebben:

code:

Client  => broadcast ("Wie is daar?")
Server1 => Client ("Ik ben er, IP is 123.123.123.123, services zijn I²C en SPI")
Server2 => Client ("Ik ben er, IP is 123.123.123.124, services zijn I²C en WS2812 (10x10 LEDs)")
...
Server9 => Client ("Ik ben er, IP is 123.123.123.132, services zijn I²C, SPI en WS2812 (1x1 LED)")

Hierna zou de client genoeg moeten weten om de servers in een lijst te plaatsen en de benodigde services aan te roepen.

[ajakkes]

AngryIPscanner?

[Xudonax]

Ik wil het resultaat vervolgens in een lijst tonen, waarna de (Java) applicatie hier dingen mee kan doen. Bijvoorbeeld een overzicht krijgen van alles wat aan de I²C bus hangt, of een serie kleuren naar de WS2812 LED's sturen. Aangezien platform onafhankelijk mijn doel is voel ik er eigenlijk weinig voor om afhankelijk te zijn van een extern programma

[CodeIT]

Wat is er mis met een broadcast sturen en zodoende je servers te detecteren? Cliient stuurt request, servers responden met een door jou gedefineerd pakket waarin de verschillende mogelijkheden worden opgesomd.

[Xudonax]

Dat is inderdaad wat ik me ook afvroeg, en ik zie niet echt een reden waarom er iets mis mee zou zijn Goed om te horen dat ik niet de enige ben.

[CodeIT]

Toevallig ben ik hier op het werk ook mee bezig. Waar je ook naar kan kijken is mDNS/bonjour/zeroconf. Voor mijn hardware was dit wat lastig te implementeren (exotische microcontroller), maar voor een PI icm Java wellicht een aardige oplossing.

[ Voor 3% gewijzigd door CodeIT op 10-05-2016 22:13 ]

[Xudonax]

Ik weet nog niet of ik op een Pi blijf of dat het iets als een NetDuino gaat worden. Zolang het een netwerk signaal kan omzetten in iets dat mijn LEDs lusten vind ik het mooi.

Na wat gepriegel werkt broadcasten in ieder geval, dus denk dat ik voorlopig daarop blijf hangen

[farlane]

Broadcasten kan uitdagingen opleveren als er meerdere netwerk adapters ( fysiek, VPN, ... ) aanwezig zijn op een apparaat. Onder .NET bijvoorbeeld moet je dan specifiek binden op een IP adres van de juiste adapter en daar op gaan broadcasten (of op allemaal).

Misschien is het relevant.

[Jeroen V]

Ander nadeel van broadcasten is dat je problemen zou kunnen krijgen als je de oplossing op een netwerkinfrastructuur wilt uitrollen die complexer is. Ik zou de voorkeur geven aan een registratiemechanisme waarbij de clients zich bij de controller registreren. (bij voorkeur op basis van fqdn)

En uiteraard alles abstract maken en achter een interface knutselen zodat je later van mechanisme kunt wijzigen als je onverhoopt nu een beslissing neemt die over een paar jaar, met vernieuwde inzichten, een minder goede oplossing blijkt.

[Ventieldopje]

Is daar niet gewoon UPnP voor? Als je java gebruikt zijn er als ik even google genoeg clients te vinden voor een simpele implementatie: http://4thline.org/projects/cling/.

Nou weet ik niet of UPnP het zelfde euvel heeft als broadcasten maar het is wel een bekende en beproefde standaard en behoud de flexibiliteit die je verliest als je iedereen laat registreren bij een vast punt.

Als je toch voor een centraal registratie punt gaat kun je het registratie punt in de configuratie stoppen van de server. Gewoon zorgen dat deze bij het opstarten (en evt. periodiek) contact maakt met het registratie punt. Mij lijkt dit toch een beetje minder "plug and play".

[ Voor 26% gewijzigd door Ventieldopje op 17-05-2016 19:20 ]

[Xudonax]

Het is een compleet custom ding (iedere "server" is een 1m² plaat gevuld met een aantal WS2812 LEDs) welke altijd op een eigen netwerk draait, hooguit dat de laptop/PC welke alles aanstuurt ook nog internet heeft, maar dat is niet eens nodig. Dingen als UPnP en dergelijke lijken met voor een dergelijke setup nogal overkill, zeker aangezien het een 100% gecontroleerde omgeving is.

Mocht dit nu daadwerkelijk op een normaal netwerk aangesloten worden dan zou het inderdaad handig zijn om naar dingen als UPnP e.d. te gaan kijken, ook om de overhead op het netwerk beperkt te houden. En dan zouden natuurlijk dingen als encryptie, authorisatie etc. ook mee gaan spelen

Qua abstractie ben ik eigenlijk bezig om een service te maken welke in de achtergrond draait en een lijst van servers bijhoud. Simpelweg een public static List<T> welke openbaar is. Java is alweer even geleden, dus ik ben nog heel erg bezig met hoe alles ook al weer precies hoort in Java. Teveel Python/C# gedaan de laatste tijd.

[johnkeates]

Er zijn zat autodiscovery protocollen, vaak ook zaken als RFC gedefinieerd, ook met UPNP, Bonjour support etc. Ook daar kan je weer extra services meegeven. Er zijn ook MCU/ulibc versies van, eigenlijk dus gewoon kant-en-klaar.

Zelf bouwen kan in theorie wel, maar dan zal je bij een bestaand netwerk mogelijk tegen problemen aan lopen die multicast filteren/blokkeren (vaak WLAN-LAN waar dat geblokkeerd wordt in AP's en CPE's), of alleen bepaalde service types ondersteunen.