FIN,ACK nach PSH,ACK

Ich versuche zu implementieren, die eine Kommunikation zwischen einem legacy-system und ein Linux-system, aber ich erhalte immer eine der folgenden Szenarien:

(Die legacy-system-server, der Linux-client)

Function recv(2) returns 0 (the peer has performed an orderly shutdown.)
> SYN
< SYN, ACK
> ACK
< PSH, ACK  (the data)
> FIN, ACK
< ACK
> RST
< FIN, ACK
> RST
> RST

Function connect(2) returns -1 (error)
> SYN
< RST, ACK

Wenn der server schickt seine Daten, sollte der client die Antwort mit den Daten, aber stattdessen bekomme ich ein "FIN, ACK"
Warum ist es so? Wie soll ich das verstehen? Ich bin nicht so vertraut mit TCP auf dieser Ebene

  • Sie müssen sich auf Ihrem client-code.
  • Die FIN könnte piggyback auf die Daten.
InformationsquelleAutor magol | 2012-11-07
  1. 1

    Wenn der server schickt seine Daten, sollte der client die Antwort mit den Daten, aber ich habe stattdessen ein "FIN, ACK" Warum ist es so? Wie soll ich das verstehen?

    Könnte es sein, dass, sobald der server die Daten versendet (Zeile 4) der AUFTRAGGEBER schließt den socket oder vorzeitig beendet und das Betriebssystem schließt das socket und sendet FIN (Linie 5). Der server antwortet FIN mit ACK aber der client hat aufgehört zu existieren und das Betriebssystem reagiert mit RST. (Ich würde erwarten, dass die client-OS im hintergrund zu ignorieren und verwerfen Sie alle TCP-Segmente kommen für eine geschlossene Verbindung während der berüchtigten TIME-WAIT Zustand, aber das passiert nicht aus irgendeinem Grund.)

    http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_termination:

    Einige host-TCP-stacks zu implementieren, die eine halb-duplex-in der Nähe-Sequenz, wie Linux oder HP-UX zu tun. Wenn so ein host aktiv schließt eine Verbindung, hat aber noch nicht alle Lesen die eingehenden Daten der stack bereits erhalten aus dem link, das der host sendet ein RST-statt einer FLOSSE (Abschnitt 4.2.2.13 in RFC 1122). Dies ermöglicht eine TCP-Anwendung, um sicherzustellen, dass der remote-Anwendung hat alle Daten Lesen die ehemaligen gesendet werden—warten auf FIN vom remote-Seite, wenn es aktiv die Verbindung schließt. Jedoch der remote-TCP-stack kann nicht unterscheiden zwischen einem Verbindungs-Abbruch der ERSTEN und dieser Datenverlust ERSTEN. Sowohl die Ursache der remote-stack wegwerfen alle Daten, die Sie erhalten, sondern dass die Anwendung immer noch nicht gelesen

    InformationsquelleAutor Maxim Egorushkin
  2. 0

    Nach FIN, PSH, ACK --> Eine Transaktion abgeschlossen
    Zweite Anforderung zu empfangen, aber senden [RST] seq=140 win=0 len=0

    InformationsquelleAutor Dee
Schreibe einen Kommentar