TCP Socket ne pas recevoir de données, écrire/envoyer ne pas timeout?

Question

J'ai fait plusieurs projets et maquettes en utilisant le socket TCP, mais c'est la première fois que je le rencontre.

J'ai une application de serveur Linux sur une machine Solaris Sparc supposée accepter une connexion d'un OCX sur un serveur Web, mais aucune donnée n'est reçue. J'ai utilisé netstat pour vérifier que la connexion a été établie.

J'ai créé un client tcp minuscule pour se connecter en tant que serveur web/ocx, mais ce qui se passe à l'écriture s'arrête là et un timeout ne se produit jamais. Même si j'ai quitté la connexion et l'attente de quelques heures, rien ne se passe. Je suis même allé jusqu'à utiliser setsockopt pour m'assurer qu'une valeur de délai d'attente basse est définie. De même, à l'autre extrémité, aucune donnée n'est reçue et l'instruction select expire pendant l'interrogation de l'ensemble fd.

Est-ce que quelqu'un a une idée pourquoi écrire ou envoyer ne serait pas expiré lors de l'écriture sur un sokcet? Aussi, quelqu'un sait-il pourquoi sur le serveur, le jeu fd lu n'a pas été défini?

ici est la décharge de Snoop:

solaris61 -> 10.1.0.37 TCP D=8882 S=35111 Fin Ack=1805515051 Seq=897643511 Len=0 Win=49640 
10.1.0.37 -> solaris61 TCP D=35111 S=8882 Ack=897643512 Seq=1805515051 Len=0 Win=24818 
solaris61 -> 10.1.0.37 TCP D=8882 S=35112 Syn Seq=921698308 Len=0 Win=49640 Options=<mss 1460,nop,wscale 0,nop,nop,sackOK> 
10.1.0.37 -> solaris61 TCP D=35112 S=8882 Syn Ack=921698309 Seq=1829645518 Len=0 Win=24820 Options=<nop,wscale 0,nop,nop,sackOK,mss 1460> 
solaris61 -> 10.1.0.37 TCP D=8882 S=35112 Ack=1829645519 Seq=921698309 Len=0 Win=49640 
solaris61 -> 10.1.0.37 TCP D=8882 S=35112 Push Ack=1829645519 Seq=921698309 Len=2 Win=49640 
10.1.0.37 -> solaris61 TCP D=35112 S=8882 Ack=921698311 Seq=1829645519 Len=0 Win=24818 

en utilisant "Snoop -x0 -s1500"

solaris61 -> 10.1.0.37 TCP D = 8882 S = 35291 Syn Seq = 4205016629 Len = 0 Win = 49640 options =

0: 0800 20f5 a3b5 000c 295d 6f44 0800 4500 .. .....)]oD..E. 
    16: 0034 e4c7 4000 4006 0000 0a01 003d 0a01 .4..@.@......=.. 
    32: 0025 89db 22b2 faa3 7635 0000 0000 8002 .%.."...v5...... 
    48: c1e8 148a 0000 0204 05b4 0103 0300 0101 .è.............. 
    64: 0402          .. 

10.1.0.37 -> solaris61 TCP D = 35291 S = 8882 Syn Ack = 4205016630 Seq = 799808987 Len = 0 Win = 24820 options =

0: 000c 295d 6f44 0800 20f5 a3b5 0800 4500 ..)]oD.. .....E. 
    16: 0034 c849 4000 4006 5e17 0a01 0025 0a01 .4.I@.@.^....%.. 
    32: 003d 22b2 89db 2fac 1ddb faa3 7636 8012 .=".../.....v6.. 
    48: 60f4 8ec1 0000 0103 0300 0101 0402 0204 `............... 
    64: 05b4          .. 

solaris61 -> 10.1.0.37 TCP D = 8882 S = 35291 Ack = 799808988 Seq = 4205016630 = 0 Len Win = 49640

0: 0800 20f5 a3b5 000c 295d 6f44 0800 4500 .. .....)]oD..E. 
    16: 0028 e4c8 4000 4006 0000 0a01 003d 0a01 .(..@.@......=.. 
    32: 0025 89db 22b2 faa3 7636 2fac 1ddc 5010 .%.."...v6/...P. 
    48: c1e8 147e 0000        .è.~.. 

solaris61 -> 10.1.0.37 TCP D = 8882 S = 35291 pousser Ack = 799808988 Seq = 4205016630 Len = 2 Win = 49640

0: 0800 20f5 a3b5 000c 295d 6f44 0800 4500 .. .....)]oD..E. 
    16: 002a e4c9 4000 4006 0000 0a01 003d 0a01 .*..@.@......=.. 
    32: 0025 89db 22b2 faa3 7636 2fac 1ddc 5018 .%.."...v6/...P. 
    48: c1e8 1480 0000 750a      .è....u. 

10.1.0.37 -> solaris61 TCP D = S = 35291 8882 Ack = 4205016632 = 799808988 Seq Len = 0 Win = 24818

0: 000c 295d 6f44 0800 20f5 a3b5 0800 4500 ..)]oD.. .....E. 
    16: 0028 c84a 4000 4006 5e22 0a01 0025 0a01 .(.J@.@.^"...%.. 
    32: 003d 22b2 89db 2fac 1ddc faa3 7638 5010 .=".../.....v8P. 
    48: 60f2 cf8c 0000 5555 5555 5555    `.....UUUUUU 

solaris61 -> 10.1.0.37 TCP D = 8882 S = 35291 Fin Ack = 799808988 Seq = 4205016632 = 0 Len Win = 49640

0: 0800 20f5 a3b5 000c 295d 6f44 0800 4500 .. .....)]oD..E. 
    16: 0028 e4ca 4000 4006 0000 0a01 003d 0a01 .(..@.@......=.. 
    32: 0025 89db 22b2 faa3 7638 2fac 1ddc 5011 .%.."...v8/...P. 
    48: c1e8 147e 0000        .è.~.. 

10.1.0.37 -> solaris61 TCP D = 35291 S = 8882 = Ack 4205016633 Seq = 799808988 Len = 0 Win = 24818

0: 000c 295d 6f44 0800 20f5 a3b5 0800 4500 ..)]oD.. .....E. 
    16: 0028 c84b 4000 4006 5e21 0a01 0025 0a01 .(.K@.@.^!...%.. 
    32: 003d 22b2 89db 2fac 1ddc faa3 7639 5010 .=".../.....v9P. 
    48: 60f2 cf8b 0000 5555 5555 5555    `.....UUUUUU 

Answer 1

Descends à tcpdump(1) et/ou snoop(1M) pour voir ce qui se passe sur le fil des deux côtés. C'est probablement la meilleure option pour trouver une explication compte tenu de la «magie» que vous décrivez. Publiez plus de détails lorsque vous les trouvez.

Answer 2

Vous obtiendriez un délai d'attente seulement s'il ne récupérait pas un accusé de réception TCP pour quelque chose qui a été envoyé. Votre vidage montre que toutes les données envoyées ont été acquittées, donc il ne devrait pas y avoir de délai. Les seules données envoyées étaient 2 octets de solaris61.

Il semble que vous disiez que vous vouliez envoyer des données à solaris61. Ces données n'ont jamais été envoyées. Comment envoyez-vous ces données?Si vous écrivez en utilisant stdio tamponné alors les données peuvent encore être dans le tampon. Par exemple, si elle est mise en mémoire tampon, elle sera mise en mémoire tampon jusqu'à ce qu'une nouvelle ligne soit envoyée. Au lieu de cela, vous pouvez désactiver la mise en tampon en utilisant setvbuf() ou simplement utiliser send() pour envoyer les données directement.

(. Si vous faites déjà cela, alors s'il vous plaît poster cette partie du code)