Python socket exception pas na tweede iteratie

[joekoe]

Momenteel ben ik bezig een simpele syslog client te schrijven in Python.

Dit lijkt in eerste instantie prima te werken maar tijdens het debuggen kwam ik een klein probleem tegen.
Als test gooi ik nu een aantal berichten in een loop naar de syslog server.

Wanneer ik tijdens het versturen van deze berichten de syslog server afsluit wordt er pas een exception weergegeven na de tweede iteratie tijdens de afgesloten syslog server.

Even de stappen simpel uitgelegd:

1.) De syslog server is gestart en ik verstuur de eerste twee berichten uit de loop zonder probleem.
2.) De syslog server "is onverwachts" afgesloten, ik verstuur nu het 3e bericht. Ik ontvang geen exception!
3.) Ik verstuur nu bericht 4, nu ziet het programma wel dat de socket is gesloten en raised een exception.

Ik mis dus in de tussentijd één bericht wat in het niets verdwijnt.
Hoe kan ik testen/ ervoor zorgen dat ik zeker weet dat de socket nog open is en/of ik zeker weet dat het bericht is aangekomen.

Relevante (test) code:

Python:

import socket

socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
socket.connect(('localhost', 514))

def send(message):
    data = "<%d>%s" % (155, message + "\n")
    try:
        #socket.sendall(test.encode('utf-8'))
        socket.sendall(data.encode('utf-8'))
        return
    except Exception as e:
        print("send failed")

messages = ["test1","test2","test3","test4","test5","test6","test7"]


for message in messages:
    send(message)

alvast dank voor de hulp!

[Merethil]

Volgens https://docs.python.org/2/howto/sockets.html wordt een socket na een send/sendall vernietigd. Je zal je socket dus moeten aanmaken en connecten in je send()-actie, niet erboven.

Edit: ah ik zie dat dit er niets mee te maken heeft. Excuus, was niet helemaal fris.

[ Voor 19% gewijzigd door Merethil op 22-12-2018 16:30 ]

[joekoe]

Merethil schreef op zaterdag 22 december 2018 @ 16:19:
Volgens https://docs.python.org/2/howto/sockets.html wordt een socket na een send/sendall vernietigd. Je zal je socket dus moeten aanmaken en connecten in je send()-actie, niet erboven.

Dankjewel, dat betekend dus dat ik voor elk bericht de socket opnieuw moet verbinden?
Er gaan straks ca. 20 berichten per seconden verstuurd worden.
Is dat dan wel helemaal de bedoeling?

Overigens in de huidige vorm hoef ik het socket niet opnieuw te verbinden. Ik kan er nu eindeloos berichten over heen sturen (tot de remote server onverwachts is gesloten) en ik pas bij de tweede iteratie nadat de remote server gesloten is een exception ontvang.

[Merethil]

joekoe schreef op zaterdag 22 december 2018 @ 16:31:
[...]


Dankjewel, dat betekend dus dat ik voor elk bericht de socket opnieuw moet verbinden?
Er gaan straks ca. 20 berichten per seconden verstuurd worden.
Is dat dan wel helemaal de bedoeling?

Overigens in de huidige vorm hoef ik het socket niet opnieuw te verbinden. Ik kan er nu eindeloos berichten over heen sturen (tot de remote server onverwachts is gesloten) en ik pas bij de tweede iteratie nadat de remote server gesloten is een exception ontvang.

Ja dat vind ik dus ook wel bijzonder. Maar merk dat dit weinig met je probleem in kwestie te maken heeft, dus had er al een edit aan gehangen... Even verder zoeken dus. Sorry!

[Mijzelf]

Zonder enige ervaring met python sockets klinkt dit me niet onlogisch in de oren, als de socket non-blocking is. In dat geval zet je de data in een output buffer, die asynchroon weggepompt wordt. Dus pas bij het schijven van bericht 4 kun je zien dat bericht 3 niet goed is weggekomen.

[joekoe]

Inderdaad. Ik heb hier wat verdere uitleg gevonden. Ik ga eens kijken of ik wat met select() kan.

https://stackoverflow.com...g-connection-closed-error

Sorry zit op mijn mobiel, Ken de tags niet uit mijn hoofd.

[farlane]

Het probleem is dat sendall returned op het moment dat je packet/data bij de netwerkstack is afgeleverd en verwerkt,maar dat wil niet zeggen dat het communicatiegedeelte al is voltooid.

Als je dat niet wilt zul je een handshake moeten inbouwen op applicatieniveau.

[joekoe]

farlane schreef op zondag 23 december 2018 @ 16:48:
Het probleem is dat sendall returned op het moment dat je packet/data bij de netwerkstack is afgeleverd en verwerkt,maar dat wil niet zeggen dat het communicatiegedeelte al is voltooid.

Als je dat niet wilt zul je een handshake moeten inbouwen op applicatieniveau.

Inderdaad, helaas zal het lastig zijn om een soort, handshake in te bouwen. ik moet gebruik maken van de bestaande syslog server die er is. Helaas geven de syslog specificaties aan dat syslog "simplex" is. Er zal dus nooit een "acknowledgement" gestuurd worden vanuit de server worden gestuurd.

[farlane]

joekoe schreef op maandag 24 december 2018 @ 12:49:
[...]
Inderdaad, helaas zal het lastig zijn om een soort, handshake in te bouwen. ik moet gebruik maken van de bestaande syslog server die er is. Helaas geven de syslog specificaties aan dat syslog "simplex" is. Er zal dus nooit een "acknowledgement" gestuurd worden vanuit de server worden gestuurd.

Syslog is inderdaad bijzonder simpel, wel zo fijn als je veel moet loggen.

Maar goed, in dat geval zou je als je merkt dat de verbinding weg is de meldingen die de laatste "x seconden" vezonden zijn als niet ontvangen moeten beschouwen en daarop actie ondernemen. Of je neemt voor lief dat niet gegarandeerd is dat alle meldingen worden gelogd, onder bijzondere omstandigheden. Als de logging zo belangrijk is dat er niets *mag* wegvallen is syslog sowieso niet geschikt.