On 01/23/2017 09:05 AM, Stefan Baur wrote:
> Am 22.01.2017 um 20:52 schrieb Peter Ludikovsky:
>
>>> Das Original mag es nicht bemerken, aber irgendwo geht dann doch im
>>> Zweifel trotzdem was hops, wenn das nicht schnell genug entgegengenommen
>>> wird.
>>> Sprich, entweder habe ich einen Stapel Tasks auf der Maschine laufen,
>>> die nicht fertig werden, und damit das RAM blockieren, das ich für die
>>> Verarbeitung der Jobs brauche, oder es werden Pakete verworfen und auf
>>> meinem Mitschnitt-Host kommen unvollständige Daten an, so dass ich keine
>>> verlässliche Kopie habe.
>>
>> Also ersteres mit großer Warscheinlichkeit nicht, wenn direkt im Kernel
>> das IP Paket geklont & sofort wieder raus geschickt wird. Und wenn der
>> Mittschnitt-Host schnell genug ist kann der ohne Probleme die Daten
>> annehmen & speichern.
>
> Ich sehe das Problem nicht in der Verarbeitungsgeschwindigkeit der
> lokalen Mascnine, sondern in
> - Netzwerkverfügbarkeit zum Mitschnitt-Host
> - Netzwerkgeschwindigkeit zum Mitschnitt-Host
> - Verarbeitungsgeschwindigkeit des Mitschnitt-Hosts
Diese Probleme wird es aber immer geben wenn du Daten über das Netzwerk
kopieren willst, und sogar zwischen lokalen Platten. So weit ich weiß
gibt es für deine Anforderungen keine fertige Lösung. Korrigiere mich
bitte falls ich hier etwas vergessen/falsch verstanden habe:
* Die Daten sollen auf einen 2. Server kopiert werden, ohne
Performance-Einbußen
* Die Daten sollen dabei ganz oder gar nicht kopiert werden
* Das Tool soll erkennen ob die Netzwerkgeschwindigkeit zu langsam ist
& dann nicht kopieren
* Das Tool soll erkennen ob die Verarbeitungsgeschwindigkeit zu langsam
ist & dann nicht kopieren
* Dabei soll nicht mehr als 1 Kopie der Daten lokal vorgehalten werden
damit der RAM nicht zu voll wird
>> Muss nicht sein. Ich kann zu wenig C um das per fork()/pthreads zu
>> basteln, aber in der Bash geht das relativ leicht:
>> ( cp <src> <dst> ) & # Job im Hintergrund starten /
>> # "fork()"
>> bpid=$! # Background-PID speichern
>> ( sleep 10; kill -9 ${bpid} ) # Wenn nach 10 Sekunden cp nicht
>> # fertig ist -> Abbruch
>> Kann etwas mehr Fehler- und Umgebugsprüfung vertragen, aber die
>> prinzipielle Funktionsweise sollte klar sein.
>
> Ne, genau das ist halt auch nix. Was auf dem Mitschnitt-Host ankommt,
> muss schon auch komplett sein.
> Sinn und Zweck im Debugging-Fall ist ja, einen "Replay" fahren zu
> können. Wenn der Datensatz dann nach 10 Sekunden abbricht, kommt nur
> Murks raus.
Gibt es irgendeine Möglichkeit, wie der Ziel-Host erkennen könnte ob die
Daten komplett sind? Z.B. ein besonderer EOF-Marker, oder eine
eingebaute Prüfsumme? Sobald die Daten da sind können sie ja ohne Hektik
geprüft werden, zeit- und resourcenkritisch ist ja (wenn ich das richtig
verstanden habe) nur die Verarbeitung am Quell-Host.
Ich habe inzwischen BTW das mit dem TEE Target bei iptables angetestet.
Da passiert tatsächlich nur ein Klonen des Pakets, wobei nur die
Ziel-MAC geändert wird. Ansonsten wird das Paket 1:1 weitergeleitet.
Lg
/peter
Attachment:
signature.asc
Description: OpenPGP digital signature