FIN,ACK après PSH,ACK

Je suis en train de mettre en œuvre une communication entre un système d'héritage et d'un système Linux, mais j'ai toujours l'un des scénarios suivants:

(Le système d'héritage est server, Linux est 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

Lorsque le serveur envoie ses données, le client doit répondre avec des données, mais au lieu de cela, je reçois un "FIN, ACK"
Pourquoi est-il comme cela? Comment dois-je interpréter cela? Je ne suis pas familier avec le protocole TCP à ce niveau

  • Vous avez besoin de regarder votre code client.
  • La FIN pourrait être greffé sur les données.
InformationsquelleAutor magol | 2012-11-07
  1. 1

    Lorsque le serveur envoie ses données, le client doit répondre avec des données, mais j'ai plutôt obtenir une "FIN, ACK" Pourquoi est-il comme cela? Comment dois-je interpréter cela?

    Il se pourrait qu'une fois que le serveur a envoyé les données (ligne 4) le client ferme la socket ou se termine prématurément et le système d'exploitation ferme sa prise et envoie FIN (ligne 5). Le serveur répond à FIN avec ACK mais le client a cessé d'exister déjà et son système d'exploitation répond avec RST. (Je m'attends à ce que le système d'exploitation client pour ignorer en silence et jeter tous les segments TCP arrivant pour une connexion fermée au cours de la tristement célèbre TIME-WAIT état, mais qui n'a pas lieu pour quelque raison.)

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

    Certains d'accueil piles TCP peut mettre en œuvre une demi-duplex à proximité de la séquence, comme Linux ou HP-UX ne. Si un tel hôte activement ferme une connexion mais n'a toujours pas lire toutes les données de la pile déjà reçu à partir du lien, cet hôte envoie une première au lieu d'une FIN (Section 4.2.2.13 dans la RFC 1122). Cela permet à une application TCP pour être sûr que l'application à distance a lire toutes les données de l'ancien envoyé en attente de la FIN du côté distant, quand elle ferme la connexion. Cependant, la télécommande pile TCP ne peut pas distinguer entre, d'une Connexion Abandon de premier et de cette Perte de Données en premier. À la fois la cause de la télécommande pile à jeter toutes les données reçues, mais que l'application n'a toujours pas lu

    InformationsquelleAutor Maxim Egorushkin
  2. 0

    Après la FIN, PSH, ACK --> Une transaction terminée
    Deuxième demande reçoit, mais l'envoi d' [RST] seq=140 win=0 len=0

    InformationsquelleAutor Dee