sichere Kommunikation über WLAN

  • Hallo,

    ich habe eine Autoit Anwendung über TCP/IP programmiert, wo ein Client Rechner Befehle an einen/mehrere Server schicken kann. Diese Server führen dann gewisse Befehle aus. Eigentlich so ähnlich wie eine Fernsteuerung für viele Computer. Funktioniert prima.

    Aber: wenn ich das ganze über eine WLAN Verbindung mache, dann werden manchmal Befehle "verschluckt", obwohl das WLAN eine noch akzeptable Signalstärke aufweist.

    Das verschlucken von Befehlen gilt es nun zu vermeiden und ich überlege mir, wie ein sicheres Protokoll zwischen den Rechner aussehen könnte.
    Gibts da schon was fertiges, leicht umzusetzendes?

    Der Sender sendet derzeit per Broadcast mehrfach - die meisten Rechner kriegen die Befehle mit, aber nicht alle.
    Wie kann ich nun sicherstellen, dass jeder Rechner den Befehl empfangen hat?
    Habt ihr Ideen?

    Vielen Dank.

  • ich würde jeder anfrage ne id geben.
    Die Anfrage mit id solange wiederholen bis sich jeder rechner mit nem id+"OK" gemeldet hat.

    Aber wird sich halt auffhängen wenn jemand ausser reichweite ist...

  • Aber wird sich halt auffhängen wenn jemand ausser reichweite ist...


    Da sollte man dann schon ein Timeout miteinbauen, sodass danach dann die Meldung kommt das der Client offline ist. Request+Response dauert keine 10ms in einem WLAN. Natürlich abhängig von der Verarbeitung auf dem Server.

  • Die Ideen sind gut. Ehrlich gesagt habe ich mich gewundert, dass es nicht schon ein Protokoll gibt, welches verhindert, dass Daten verloren oder beschädigt ankommen.
    Alleine schon deswegen, weil ja jeder, der über das Netzwerk was verschickt, sicher stellen muss, dass die Info unversehrt und vollständig ankommt...

  • Hat TCP so etwas nicht schon selber im Aufbau drin? Eine Prüfsumme um zu erkennen 1.) In welcher Reihenfolge die Pakete ausgewertet werden und 2.) Ob eins fehlt. Ein Paket wird doch (in TCP) so oft gesendet bis es ankommt (Oder ein Timeout entsteht/Wenn Client off geht, aber das könntest du ja nach TCPSend() mit einem If @Error = prüfen).

    mfg BB

    "IF YOU'RE GOING TO KILL IT
    OPEN SOURCE IT!"

    by Phillip Torrone

    Zitat von Shoutbox

    [Heute, 11:16] Andy: ....böseböseböseböse....da erinnere ich mich daran, dass man den Puschelschwanz eines KaRnickels auch "Blume" nennt....ob da eins zum anderen passt? :rofl: :rofl: :rofl: :rofl:

    https://autoit.de/index.php?page…leIt#post251138

    Neon Snake

  • Bei einem Broadcast ist dem Sender aber nicht bekannt wieviele Empfänger es gibt und somit kann er auch nicht wissen wer alles drauf antworten sollte.


    Warum versendest du überhaupt einen Broadcast? Auch eher ungewöhnlich ist es doch, dass du viele Server und wenige Clienten hast, warum nicht einen fixen Server im Netz und viele Clienten, die sicht automatisch beim Server anmelden (sofern erreichbar). Dann weiß dein Server welche clienten vorhanden (online) sind und kann Befehle an diese dauerhaft verbundenen Clienten senden. Grundsätzlich sollte TCP bei direkter Unicast Kommunikation auch gewährleisten, dass alles da ankommt wo es hin soll. Zur verifizierung auf Protokollebene könntest du aber auch auf eine Bestätigung der Clienten warten, dass der Befehl angekommen, verstanden und ausgeführt wurde.

  • Also ich frage mich ehrlich gesagt wie du es überhaupt geschafft hast irgendetwas über TCP per Broadcast zu schicken. TCP ist nämlich nicht Broadcastfähig und zwar aus dem simplen Grund dass es ein ankommen der Daten garantiert. Und das wäre ja genau das was du willst aber per Broadcast geht das schon aus Logischen gründen nicht. Wie willst du überprüfen ob alle Server die Nachricht erhalten haben wenn du die Server nicht kennst? Und wenn du die Server kennst ist Broadcast definitiv überflüssig. Verwende entweder UDP als Broadcast und überleg dir ein System wie du rausfinden kannst ob alle Server geantwortet haben oder mach das ganze Unicast per TCP. Wäre die bessere Variante.

    Gruss Shadowigor

  • Hallo,
    also ich muss mich bei euch für die falsche Info entschuldigen. Natürlich nutze ich UDP als Broadcast. Ich habe mir damals keine Gedanken darüber gemacht, dass Infos verloren gehen könnten und war froh, dass ich mit dem Broadcasting extrem wenig Aufwand habe.

    Der Sender schickts einfach raus und jeder der zuhört empfängt es und führt es aus. Eigentlich auch genau richtig für diese Anwendung, wenn halt nicht die Paketverluste auftreten würden...

    Also muss ich auf TCP umstellen? Jeder Teilnehmer muss sich anmelden. Dann schicke ich jedem Teilnehmer einen Aus/Einschaltbefehl. Muss der das dann noch quitieren, oder kann ich mich wegen TCP drauf verlassen, dass der das bekommen hat?

    Wie könnte ich eine Synchronität hinbekommen?
    Die ferngesteuerten Rechner sollen z.B. alle die gleichen Soundfiles abspielen. Da wäre es Klasse, wenn alle ungefähr gleichzeitig die Befehle empfangen könnten...

  • Bei TCP kannst du dich darauf verlassen, dass es ankommt. Du kannst natürlich auch einen UDP Broadcast schicken und jeden der antwortet packst du in eine Liste. Dann kannst du mit jedem in dieser List eine TCP Verbindung aufbauen. Zur Synchronität musst du die Befehle einfach direkt hintereinander, am besten in einer Schleife, an jeden Server senden. Das sollte zeitlich eigentlich synchron genug sein.

  • Zur Synchronität musst du die Befehle einfach direkt hintereinander, am besten in einer Schleife, an jeden Server senden. Das sollte zeitlich eigentlich synchron genug sein.

    Sollte das aufgrund der Menge der Clients und Netzwerklatenzen nicht der Fall sein, könnte man das ganze zeitlich synchronisieren. Das setzt vorraus, dass alle Clienten die selbe Uhrzeit haben (z.B. gemeinsamer Timeserver). Der Server kombiniert den Befehl dann mit einem Ausführungsdatum/zeitpunkt welche ausreichend in der Zukunft liegt, um Latenzprobleme zu umgehen. Alle Clienten warten nach Erhalt des Befehls ab bis diese Ausführungszeitpunkt erreicht wurde und starten dann zeitgleich mit der Ausführung.

    Letzten Endes reden wir hier aber vermutlich nur von Latenzen im ms Bereich, was den Aufwand einer Synchronisation vermutlich nicht rechtfertigt.