Aufgabe zu TCP-Zustandsautomat



  • Hi,
    unser Prof. in Rechnernetze hat mal eine ziemlich fiese Aufgabe gebracht, wo es m. A. n. keine saubere Lösung im Sinne des TCP-Zustandsautomats gibt.

    Der Automat ist hier verlinkt:

    http://image-upload.de/image/S3xYvB/c9a8ea7853.png

    Vielleicht sollte gesagt sein, dass die Pfeile folgendermaßen bezeichnet sind: Empfangen/Senden

    Die Aufgabe: Zwei Teilnehmer machen einen simultanes Close, dabei geht eines der TCP-Segmente verloren. Man soll beide Möglichkeiten aufzeigen.

    Mein Lösungsansatz:
    - Die Teilnehmer müssen also beide im Zustand "Established" sein.
    - Sie kriegen dabei gleichzeitig ein Close-Event und senden ein TCP-Paket mit dem Finish-Flag.
    - Sie landen sofort im Zustand Fin Wait 1.
    - Angenommen, das Fin-Paket von Teilnehmer B geht verloren:
    - Teilnehmer B empfängt von A ein fin-Packet --> Er sendet ein Ack-Packet.
    - B ist jetzt im Zustand Closing.
    - Hiermit frieren die Zustände der Teilnehmer ein, weil:
    - A ist immer noch im Fin Wait 1 Zustand und wartet auf ein Fin-Packet von B, das aber verloren ging.
    - B ist im Closing-Zustand und wartet auf ein Ack-Packet von A, das aber niemals gesendet wird, weil das Fin-Packet von B verloren ging.

    Die geforderte zweite Möglichkeit ist m. A. n. genau analog, nur dass eben bei Teilnehmer A das Fin-Packet verloren geht.

    Wird der Closed-Zustand tatsächlich nie erreicht?!

    Gruß,
    IBV



  • - Sie landen sofort im Zustand Fin Wait 1.
    - Angenommen, das Fin-Paket von Teilnehmer B geht verloren:
    - Teilnehmer B empfängt von A ein fin-Packet --> Er sendet ein Ack-Packet.
    - B ist jetzt im Zustand Closing.
    - Hiermit frieren die Zustände der Teilnehmer ein, weil:
    - A ist immer noch im Fin Wait 1 Zustand und wartet auf ein Fin-Packet von B, das aber verloren ging.

    Also erstmal hast du vergessen dass A ja noch das ack von B empfängt, und daher in den Zustand FIN WAIT-2 wechselt.
    Macht aber natürlich keinen grossen Unterschied ob A jetzt in FIN WAIT-1 oder FIN WAIT-2 festhängt.

    Was in dem Diagramm aber fehlt sind etliche Stellen wo es in der Praxis Retries und Timeouts gibt.
    z.B. gibt es in ESTABLISHED Retries und dann irgendwann ein Timeout wenn ein gesendetes Datenpaket nicht bestätigt wird (ack).

    Und genau so gibt es in FIN WAIT-1, FIN WAIT-2 und CLOSING Retries und Timeouts das erwartete Paket nicht kommt.
    Wobei ihr das vermutlich ignorieren sollt, und die Sache wirklich nur anhand des Diagramms beurteilen.

    IBV schrieb:

    Die geforderte zweite Möglichkeit ist m. A. n. genau analog, nur dass eben bei Teilnehmer A das Fin-Packet verloren geht.

    Naja, es könnte ja auch eines der beiden "ack" verlorengehen.

    Wird der Closed-Zustand tatsächlich nie erreicht?!

    In der Praxis landet man immer irgendwann in CLOSED. Siehe oben.
    (Ausser natürlich in Fällen wie z.B. wenn der eigene PC in ESTABLISHED ist, und nie versucht etwas zu senden, und die Gegenstelle "verschwindet" einfach -- dann bleibt der eigenen PC quasi für immer in ESTABLISHED. Zumindest wenn die Keep-Alive Option nicht verwendet wird.)



  • Super, danke hustbaer! Hat mir weitergeholfen! 🙂

    L. G.,
    IBV


Log in to reply