
Auf welche Eigenschaften sollte ich bei einem Wireless Access Point achten, der 50 Geräte für die Peer-to-Peer-Kommunikation verbinden soll? Meine größte Sorge ist, dass alle Geräte eine zuverlässige Verbindung aufrechterhalten und Pakete zuverlässig übermitteln.
Meine Anforderungen:
- 1 großer Raum mit wenigen Hindernissen
- 100 KB/s Durchsatz pro Gerät, gleichzeitig mit allen Geräten
- Zuverlässige WLAN-Verbindung (bei Sendefehlern wird die gesamte App angehalten, bis alle Geräte auf dem gleichen Stand sind).
- Gemischt 802.11 g/n
Wenn ein Gerät Informationen veröffentlicht, empfängt eine große Teilmenge aller anderen Geräte diese sofort. Die Informationen sind normalerweise 10 bis 100 KB groß. Die Veröffentlichungsrate auf allen Geräten liegt bei 5 pro Sekunde.
Antwort1
[Haftungsausschluss: Ich habe diese Antwort geschrieben, bevor ich oben eine Klarstellung erhalten habe. Ich muss diese Antwort basierend auf meinem besseren Verständnis neu schreiben, aber vorerst lasse ich sie so, wie sie ist, falls sie jemand anderem hilft, der ein Wi-Fi-Netzwerk für ein 50-Peer-Multicast-Protokoll entwirft.]
Beachten Sie, dass Multicasts/Broadcasts und WLAN nicht zusammenpassen
Dies ist vermutlich nicht die Antwort, nach der Sie gesucht haben, aber es ist vermutlich das Wichtigste, was Sie berücksichtigen müssen.
Bei kabelgebundenem Ethernet, insbesondere mit Switches, waren Multicasts kostengünstiger als separate Unicasts. Bei drahtlosem Ethernet (Wi-Fi) erhalten Multicasts und Broadcasts jedoch keine Link-Layer-Bestätigungen, da dies für jedes Multicast einen schwer zu bewältigenden Bestätigungssturm verursachen würde. Daher müssen Multicasts mit einer ausreichend niedrigen Datenrate gesendet werden, damit jeder Client dieses APs sie zuverlässig empfangen kann (niedrigere Raten sind im Allgemeinen einfachere Modulationen, die bei größerer Reichweite oder in lauteren Umgebungen zuverlässiger empfangen werden). Dies bedeutet, dassEin Multicast-Paket benötigt normalerweiseviele Malemehr Sendezeit (Bandbreite) als ein Unicast-Paket derselben Größe.
Es ist ziemlich üblich, dass ein 2,4-GHz-WLAN-AP standardmäßig Multicasts mit einer Datenrate von 1 Megabit/s sendet. Wenn ich Ihre Bandbreitenanforderungen richtig verstanden habe, wäre das etwas weniger als ein Viertel der Bandbreite, die Ihr Protokoll benötigt (vorausgesetzt, Ihr Protokoll verwendet Multicast, was wahrscheinlich der Fall zu sein scheint).
Sie müssen also sicherstellen, dass Ihr AP beim Senden von Multicasts mindestens die 5,5 MBit/s-Rate oder wahrscheinlich mehr verwendet. Sie müssen auch sicherstellen, dass sich alle Ihre Geräte in Reichweite befinden, um diese Datenrate zuverlässig zu empfangen (wahrscheinlich nicht schwierig in einem großen, aber nicht riesigen Raum ohne Hindernisse).
Oops, I almost forgot to account for Intra-BSS Relay. When using Wi-Fi with an AP (as opposed to "IBSS" a.k.a. "Ad-hoc" mode), the AP relays all transmissions from one wireless client to another. This allows the network to cover a wider area, as clients don't need to all be in range of each other, they just each need to be in range of the AP. So your 4+ mbps of data is going to be sent at a unicast data rate from the sending client to the AP, and then relayed by the AP at the multicast rate. So if during one peak one-second period, the clients sending each of the five 100 KibiByte transmissions all happen to be on the edge of the network where they can only maintain the 5.5 megabit per second data rate, that means that it would take almost two full seconds to get all of that "one-peak-second's worth" of date multicasted out to all of the clients. So, yeah, the 5.5 mbps data rate isn't going to work for you either. Shoot for the 12 mbps data rate as your multicast rate, and make sure all of your clients are "within 12mbps range" so to speak.
So, make sure your Wi-Fi lets you set what rate multicasts are sent at. Some APs let you set this explicitly, whereas others may derive the multicast rate from other settings. For example, if it lets you set the Basic Rates (i.e. required rates), it may pick the lowest Basic Rate for the multicast rate. Or if it lets you disable 802.11b rates, it may pick the lowest G rate (6mbps) as the multicast rate. Apple's APs tend to let you set the multicast rate by an obscure low/medium/high rubric, for which there's a decoder table here: How To Set Multicast Rate On Apple AirPort Extreme
Other things to think about:
Make sure your application-layer protocol is handling the need for retransmissions, since multicasts over Wi-Fi are not guaranteed to be reliable. Take your average retransmission rate into account when calculating your bandwidth (and thus multicast rate) needs.
Make sure you use a clean channel. My multicast rate calculations assumed a perfectly clean channel. If other nearby users are keeping the channel busy, say, half the time, then you'd need to at least double the multicast rate from what I'd previously calculated..
Some older APs that advertised a 50 client limit did so because their hardware had a limit to how many separate per-client unicast keys they could keep track of. Some had a hard limit there, but others used software to handle more keys than could be handled in hardware, but took a small performance hit for it. Probably not a problem in your situation, but if you have any problem with getting 50 clients on at the same time, and you started out with WPA2 (or WPA) enabled, try it without any wireless security enabled instead.
Wenn Sie WPA2- (oder WPA-)Sicherheit benötigen, versuchen Sie zu verhindern, dass die Client-Geräte in den Ruhezustand wechseln oder das Netzwerk auf andere Weise verlassen. Jedes Mal, wenn ein Client das Netzwerk verlässt, muss der Gruppenschlüssel (der zum Verschlüsseln von Multicast-/Broadcast-Paketen) geändert werden. Dies erfordert eine Menge Netzwerkaktivität, die die für Ihre Multicasts verfügbare Sendezeit aufzehren würde. Es verzögert auch alle weiteren Multicasts, bis alle verbleibenden Clients den Empfang des neuen Gruppenschlüssels bestätigt haben, und führt dazu, dass der AP alle Clients trennt, die den Empfang des neuen Gruppenschlüssels nicht bestätigt haben. Dies führt zu weiteren kleinen Aktivitätsschüben, wenn diese verlassenen Clients wieder ins Netzwerk zurückkehren.