Encore un Autre "Connection reset by peer' Erreur
Je suis en création d'un serveur/client de l'application en python à l'aide de la douille du module et pour quelque raison que ce soit mon serveur continue à la fin de la connexion. Ce qui est étrange, c'est que dans Windows parfaitement, mais pas Linux. Je l'ai cherché partout une solution possible mais aucun d'entre eux travaillaient. Ci-dessous est une version aseptisée du code qui exploite le bug, cependant, avec un taux de réussite plus élevé. Normalement, ça ne fonctionne jamais. J'espère que c'est encore assez d'informations. Merci!
Serveur:
import logging
import socket
import threading
import time
def getData():
HOST = "localhost"
PORT = 5454
while True:
s = socket.socket( socket.AF_INET, socket.SOCK_STREAM )
s.setsockopt( socket.SOL_SOCKET, socket.SO_REUSEADDR, 1 ) #because linux doesn't like reusing addresses by default
s.bind( ( HOST, PORT ) )
logging.debug( "Server listens" )
s.listen( 5 )
conn, addr = s.accept()
logging.debug( "Client connects" )
print "Connected by,", addr
dataRequest = conn.recv( 1024 )
logging.debug( "Server received message" )
time.sleep( .01 ) #usually won't have to sample this fast
data = """Here is some data that is approximately the length
of the data that I am sending in my real server. It is a string that
doesn't contain any unordinary characters except for maybe a tab."""
if not timeThread.isAlive(): #lets client know test is over
data = "\t".join( [ data, "Terminate" ] )
conn.send( data )
s.close()
print "Finished"
print "Press Ctrl-C to quit"
break
else:
logging.debug( "Server sends data back to client" )
conn.send( data )
logging.debug( "Server closes socket" )
s.close()
def timer( t ):
start = time.time()
while ( time.time() - start ) < t:
time.sleep( .4 )
#sets flag for another thread not here
def main():
global timeThread
logging.basicConfig( filename="test.log", level=logging.DEBUG )
#time script runs for
t = 10 #usually much longer (hours)
timeThread = threading.Thread( target=timer, args=( t, ) )
dataThread = threading.Thread( target=getData, args=() )
timeThread.start()
dataThread.start()
#just for testing so I can quit threads when sockets break
while True:
time.sleep( .1 )
timeThread.join()
dataThread.join()
if __name__ == "__main__":
main()
Client:
import logging
import socket
def getData():
dataList = []
termStr = "Terminate"
data = sendDataRequest()
while termStr not in data:
dataList.append( data )
data = sendDataRequest()
dataList.append( data[ :-len( termStr )-1 ] )
def sendDataRequest():
HOST = "localhost"
PORT = 5454
s = socket.socket( socket.AF_INET, socket.SOCK_STREAM )
while True:
try:
s.connect( ( HOST, PORT ) )
break
except socket.error:
print "Connecting to server..."
logging.debug( "Client sending message" )
s.send( "Hey buddy, I need some data" ) #approximate length
try:
logging.debug( "Client starts reading from socket" )
data = s.recv( 1024 )
logging.debug( "Client done reading" )
except socket.error, e:
logging.debug( "Client throws error: %s", e )
print data
logging.debug( "Client closes socket" )
s.close()
return data
def main():
logging.basicConfig( filename="test.log", level=logging.DEBUG )
getData()
if __name__ == "__main__":
main()
Edit: Ajout de l'exī
Traceback (most recent call last):
File "client.py", line 39, in <moduel>
main()
File "client.py", line 36, in main
getData()
File "client.py", line 10, in getData
data = sendDataRequest()
File "client.py", line 28, in sendDataRequest
data = s.recv( 1024 )
socket.error: [Errno 104] Connection reset by peer
Edit: Ajouté le débogage
DEBUG:root:Server listens
DEBUG:root:Client sending message
DEBUG:root:Client connects
DEBUG:root:Client starts reading from socket
DEBUG:root:Server received message
DEBUG:root:Server sends data back to client
DEBUG:root:Server closes socket
DEBUG:root:Client done reading
DEBUG:root:Server listens
DEBUG:root:Client sending message
DEBUG:root:Client connects
DEBUG:root:Client starts reading from socket
DEBUG:root:Server received message
DEBUG:root:Server sends data back to client
DEBUG:root:Client done reading
DEBUG:root:Client sending message
DEBUG:root:Client starts reading from socket
DEBUG:root:Server closes socket
DEBUG:root:Client throws error: [Errno 104] Connection reset by peer
DEBUG:root:Server listens
Tom théorie semble être correcte. Je vais essayer de trouver comment fermer la connexion mieux.
Ce n'est pas résolu, mais l'on a accepté la réponse semble signaler le problème.
Edit: j'ai essayé à l'aide de Tom de la fonction getData() et il semble que le serveur ferme la connexion trop tôt. Doit être reproductible puisque je ne pouvais pas le faire fonctionner sous Windows.
Sortie Du Serveur/Traceback:
Connected by, ('127.0.0.1', 51953)
Exception in thread Thread-2:
Traceback (most recent call last):
File "/usr/lib64/python2.6/threading.py", line 532, in __bootstrap_inner
self.run()
File "/usr/lib64/python2.6/threading.py", line 484, in run
self.__target(*self.__args, **self.__kwargs)
File "server.py", line 15, in getData
s.bind( ( HOST, PORT ) )
File "<string>", line 1, in bind
error: [Errno 22] Invalid argument
De Sortie Du Client/Traceback:
Here is some data that is approximately the length
of the data that I am sending in my real server. It is a string that
doesn't contain any unordinary characters except for maybe a tab.
Traceback (most recent call last):
File "client.py", line 49, in <moduel>
main()
File "client.py", line 46, in main
getData()
File "client.py", line 11, in getData
data = sendDataRequest()
File "client.py", line 37, in sendDataRequest
print data
UnboundLocalError: local variable 'data' referenced before assignment
Journal:
DEBUG:root:Server listens
DEBUG:root:Client sending message
DEBUG:root:Client connects
DEBUG:root:Client starts reading from socket
DEBUG:root:Server received message
DEBUG:root:Server sends data back to client
DEBUG:root:Server closes connection
DEBUG:root:Client done reading
DEBUG:root:Client closes socket
DEBUG:root:Client sending message
DEBUG:root:Client starts reading from socket
DEBUG:root:Client throws error: [Errno 104] Connection reset by peer
Mise à jour: j'ai utilisé de Tom getData()
fonction, mais déplacé le s.bind()
à l'avant de la boucle et il a obtenu de travailler. Honnêtement, je ne sais pas pourquoi cela fonctionne si ce serait cool si quelqu'un pourrait-il expliquer pourquoi le serveur de la fermeture de la socket client est sûr, mais pas quand il ferme la socket serveur. Merci!
nc
?Pouvez-vous donner plus de speciifc de l'information sur la mesure à la fois le serveur et le client obtenez avant de vous rencontrez l'erreur - et ce que l'erreur exacte/trace de la pile est à la fois client et serveur?
Je ne vois pas comment il pourrait être un problème de connectivité avec localhost, mais je peux le faire en quelques minutes
Bien sûr, je vais la poster dans quelques minutes. Quant à la distance, habituellement de 5 secondes. Parfois, il se termine (10s), mais jamais plusieurs fois dans une rangée.
Vous du serveur
while True
boucle semble garder l'ouverture d'un nouveau socket, sans aucun signal de la part du client que le support est fini ou que le client a fini de lire les données - est-ce intentionnel?
OriginalL'auteur smbullet | 2014-07-21
Vous devez vous connecter pour publier un commentaire.
Alors que je ne peux pas reproduire ce problème (sur Windows 7 64-bit, Python 2.7), ma meilleure supposition est que la suite se passe:
La stacktrace vous avez ajouté de la part du client semble à l'appui de cette théorie. Est-il possible de prouver que n'est pas le cas avec certains enregistrements supplémentaires ou similaires?
D'autres choses à noter:
Si votre client ne trouve pas le résilier chaîne dans le premier les données qu'il reçoit, il ouvre une nouvelle socket vers le serveur. Qui ressemble de mal à m' - vous devriez lire les données à partir du même support jusqu'à ce que vous l'avez tous.
Edit: Quelques plus de choses:
Dans votre exemple de la sortie du journal, vous n'avez pas mis à jour le code donc je ne peux pas voir où chaque ligne de journal vient de. Toutefois, il semble louche, comme vous avez 2 clients exécutant en parallèle (dans différents processus ou threads peut-être?), ce qui conduit à:
Je viens de remarquer une dernière chose. Dans l'exemple ici https://docs.python.org/2/library/socket.html#example le serveur ne ferme pas la prise, il ferme la connexion généré à partir de l'écoute sur la prise. Il se peut que vous ayez 2 clients connectés au même serveur de socket exemple, lorsque vous fermez le socket serveur vous de vous déconnecter à la fois les clients connectés, pas seulement la première. Si vous exécutez plusieurs clients se connectant ensuite une sorte d'identité par exemple.
DEBUG:root:Client(6) done reading
peut aider à prouver que l'.Pourriez-vous essayer ce qui suit pour le serveur de données du fil boucle principale, permettra de voir si le problème est lié à la fermeture de la socket d'écoute plutôt que le socket connecté:
Avez-vous regardé à l'aide de la
logging
paquet en python? C'est thread-safe hors de la boîte.Je n'ai pas, mais je peux lui donner un look.
Que recherchez-vous? Voulez-vous simplement me connecter à chaque fois qu'une connexion est établie et les données envoyées/reçues avec un timestamp?
Essayer de prouver si ma théorie ci-dessus est correcte ou pas!
OriginalL'auteur Tom Dalton
Je suis hors de ma profondeur ici, mais en regardant dans un éventuel problème lié (intermittent "connection reset by peer" erreurs sur Linux, fonctionne très bien sur Windows), et je suis tombé sur http://scie.nti.st/2008/3/14/amazon-s3-and-connection-reset-by-peer/. Avec l'aide de notre débogueur de là, Garry Dolley, résume (en 2008!):
"Noyaux Linux 2.6.17+ augmentation de la taille maximale de la fenêtre TCP/tampon, et cela a commencé à cause d'autres engins à la perruque, s'il n'a pas pu traiter suffisamment grande fenêtre TCP. Les engins de réinitialiser la connexion, et nous voyons cela comme une "Connection reset by peer" message."
Il donne une solution impliquant /etc/sysctl.conf. Je n'ai pas essayé encore, mais peut-être vaut un coup d'oeil?
OriginalL'auteur Jacob Eliosoff