Protokolle zur Netzwerk-Kommunikation

• Fragestellung:
  • Wie kann man eine große Datei sicher über das Internet verschicken?
  • Grundprinzip
    • Datei in Blöcke zerlegen
    • Blöcke verschicken (ggf. auf verschiedenen Wegen)
    • beim Empfänger einsammeln und auf Vollständigkeit prüfen
    • ggf. fehlende Blöcke nachfordern
• Grundsätzlicher Modell-Aufbau:
  • Generator erzeugt große Datei
  • Zerleger macht daraus viele Einzelblöcke und schickt sie weiter
  • Router schickt Blöcke weiter, wählt einen von mehreren Wegen
  • Empfänger sammelt Blöcke ein und erzeugt komplette Nachricht
• Stark vereinfacht, es fehlt z. B.:
  • dynamische Wahl des Weges durch komplexes Netzwerk
  • Verlorengehen von Blöcken
    
    • → keine Nachforderung fehlender Blöcke
  • volle Komplexität in den Protokollen TCP und IP
• Interessierende Größen:
  • Durchsatz (MB/s) bei kleinen/großen Dateien
  • Zeit Sender - Empfänger
  • Verhalten bei mehreren Dateien, z. B.
    • zwei große Dateien parallel
    • eine große Datei + viele kleine
• Grundbeispiel sendmessage1A:
  • eine Nachricht auf zwei Wegen
    • 
  • Generator
    • erzeugt eine große Nachricht
    • ≙ eine Entität mit Attributen messageId, size (in Blöcken), destination, blockId (für später)
    • Maske mit Parametern für messageId, size, destination, Erzeugungszeit t0
  • Berechnung der Intergeneration time
    • persistent index;
      if isempty(index)
        index = 1;
      end
      times = [t0, inf];
      dt = times(index);
      index = index + 1;
  • Fragmentation
    • zerlegt Nachricht in Blöcke
    • 
    • Entity Replicator erzeugt size Kopien
    • Server mit fester Zeit 0.1s → Blöcke kommen in kurzen Zeitabständen
    • Queue als Zwischenspeicher, setzt blockId in Entry action
  • Router
    • verteilt Blöcke auf zwei Wege
    • 
    • verwendet Verteilmethode Equiprobable
    • hat eigenen Zwischenspeicher
  • Leitung (Line)
    • Server mit unendlicher Kapazität
    • feste, aber pro Line unterschiedliche Servicezeit (= Laufzeit)
  • Anzeige der blockIds (Path1a etc.)
    • Display-Variante mit Masken-Parameter attrib zur Auswahl des angezeigten Attributs
    • Eigenschaft Evaluate von attrib ist off
    • Masken-Initialisierung setzt Entry action des Servers
    • varName = ['entity.', strtrim(attrib)];
      block = [gcb, '/EntityServer'];
      set_param(block, 'PostArrivalFunction', ['showValue(' varName ');']);
  • Assembler
    • Standard-Komponente Entity Batcher
    • sammelt feste Zahl von Entitäten in einer einzelnen Batch-Entität
    • Batch-Entität intern Array der Einzel-Entitäten
  • Ergebnis
    • 
• Dynamischer Assembler (sendmessage1B):
  • Problem: Entity Batcher verwendet feste Zahl von Blocks, nicht aus Message
  • besser: Länge N der Message aus Message-Attribut
    • Idee: N-1 ankommende Blöcke vernichten, N-ten durchlassen
    • letzter Block repräsentiert dann komplette Message
    • wir sind nicht an der genauen Nachbildung der Message interessiert, sondern nur am Routing-/Zeitverhalten
  • Implementierung
    • 
    • Queue steuert Output Switch über Entry Action
    • persistent count;
      if isempty(count)
        count = 1;
      end
      if count == entity.size
        port = 1;
      else
        port = 2;
      end
      count = count + 1;
      createMessage(port);
    • Queue sammelt nicht, aber es gibt keinen "Durchlauf"-Block mit Entry oder Exit Action
    • Simulink Function createMessage erzeugt Message (wie oben)
  • Verhalten identisch zu vorher bei n = 10, klappt auch bei n = 20
  • Problem bei n = 30: nur 25 Blöcke werden erzeugt
    • Ursache: FIFO bei Fragmentation zu klein
  • sendmessage1C hat großen FIFO → alles ok
• Erweiterung des Leitungsmodells:
  • Komponente Line
    • Durchlaufzeiten exponentiell verteilt
    • maximale Kapazität als Parameter
    • zusätzlich Ausgabe der momenten Auslastung
    • 
  • Problem: viele Blöcke mit Zufallswerten
    • verwenden alle verschiedene Zufalls-Streams (wegen Übersetzung nach C++)
    • brauchen verschiedene Seeds
    • häufiger Trick: eine generelle Seed, andere Blöcke addieren Konstanten
    • bei vielen Blöcken unübersichtlich und fehleranfällig
  • bessere Lösung
    • ein globaler Stream im Modell
    • in Action-Funktionen Matlabs rand-Funktion verwenden: coder.extrinsic('rand');
    • modell-globale Seed setzen per InitFcn()
  • Gesamtmodell sendmessage2A
    • 
  • Router verwendet Methode round-robin
  • Ergebnis
    • 
• Schicken einer längeren Nachricht:
  • andere Parameter (sendmessage2B)
    • unterer Weg langsamer, kleinere Kapazität
  • Ergebnis
    • 
  • Analyse
    • untere (rote) Leitung ausgelastet, blockiert
    • → alle anderen Leitungen warten (wegen round-robin)
  • Übertragungszeit 17.1 s
  • Routing umstellen auf First port that is not blocked (sendmessage2C)
    • 
    • Blöcke verwenden Line1, bis die voll ist, dann auch Line2
    • besser: Lines gleichmäßig auslasten
  • Übertragungszeit 12.4 s
• Verbessertes Routing (sendmessage2D):
  • adaptiver Routing-Algorithmus
    • Auslastungen der Lines werden an Router gemeldet
    • Router wählt immer Leitung mit kleinster Auslastung
  • Gesamtmodell
    • aktuelle Auslastungen der Lines gehen zum Router
    • 
  • Router
    • 
    • Matlab-Funktion liefert Index des kleinsten Werts
    • [~, y] = min(u);
    • erzeugt Message zur Steuerung des Output Switch
  • Ergebnis
    • 
    • Übertragungszeit wie vorher, da kein Engpass
    • Leitungen gleichmäßig ausgelastet
• Störung in einer Leitung (sendmessage2E):
  • ab t > 10s Transportzeit auf Line1 5x so lang
    
  • Implementierung
    • 
    • Berechnung der Service Time
    • coder.extrinsic('rand');
      dt = 1.0;   % tell coder type of result
      if getTime() < 10
        dt = -delay*log(rand());
      else
        dt = -5*delay*log(rand());
      end
    • verwendet Simulink-Funktion getTime()
    • 
  • Ergebnis
    • 
    • Übertragung dauert etwas länger
    • Auslastungen bleiben gleichmäßig
• Aufgaben:
  • Aufgabe 17