Bitcoin2017 Geschrieben 11. Dezember 2017 Teilen Geschrieben 11. Dezember 2017 Hi, ich habe ein Python Script für die websockets geschrieben. Allerdings wird die Verbindung immer nach ca. 86-90 Sekunden geschlossen - vom Server. Ich habe jetzt schon mehrere Varianten getestet - es ist immer der Server der die Verbindung beendet. Insofern ich zusätzlich eine Nachricht sende - als Keep-Alive - wird es auch nicht besser, bei einem Ping wird die Verbindung gleich geschlossen. Soll das so sein? Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
matthias.linden Geschrieben 12. Dezember 2017 Teilen Geschrieben 12. Dezember 2017 Bekommst du zwischendurch Daten ausgeliefert? Oder sind die 90 Sekunden der Timeout der zugrundeliegende https Verbindung? Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Bitcoin2017 Geschrieben 12. Dezember 2017 Autor Teilen Geschrieben 12. Dezember 2017 Ja, Daten kommen. Dann auf einmal beendet der Server die Verbindung. Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Bitcoin2017 Geschrieben 12. Dezember 2017 Autor Teilen Geschrieben 12. Dezember 2017 Ergänzung dazu, es scheinen max. 86 Abfragen (getdata) möglich zu sein, bevor der Server die Verbindung schließt. Bei Erhöhung des eines Sleep timers auf 2 Sekunden bleibt die Session auch doppelt so lange aktiv. Warum ist das so? Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Doncarlos Geschrieben 12. Dezember 2017 Teilen Geschrieben 12. Dezember 2017 vor einer Stunde schrieb Bitcoin2017: Ergänzung dazu, es scheinen max. 86 Abfragen (getdata) möglich zu sein, bevor der Server die Verbindung schließt. Bei Erhöhung des eines Sleep timers auf 2 Sekunden bleibt die Session auch doppelt so lange aktiv. Warum ist das so? Hi, Kann es sein, dass Du da etwas falsch implementiert hast ? Der Unterschied zum Polling ist bei den Websockets ja gerade eben, dass der Server Daten schickt wenn er welche/neue hat. Es ist nicht Sinn und Zweck, dass Du sie permanent abfrägst. Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Bitcoin2017 Geschrieben 12. Dezember 2017 Autor Teilen Geschrieben 12. Dezember 2017 Ich frage nur den internen Recv Buffer ab, es sind keine GET requests. Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Doncarlos Geschrieben 12. Dezember 2017 Teilen Geschrieben 12. Dezember 2017 vor 2 Stunden schrieb Bitcoin2017: Ich frage nur den internen Recv Buffer ab, es sind keine GET requests. Anscheinend ja nicht :-) Wäre Deine Aktion rein auf Deinen Rechner beschränkt, würde es keinen Unterschied machen ob du alle 2 Sekunden oder alle 2 MS den Buffer abfrägst. Wirf doch mal deinen Code in den Ring, dann sieht man mehr Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Bitcoin2017 Geschrieben 12. Dezember 2017 Autor Teilen Geschrieben 12. Dezember 2017 Klar, hier: import websockets <get hskey via requests> async with websockets.connect ('wss://ws.bitcoin.de/socket.io/1/websocket/' + str (hskey)) as websocket: try: while True: greeting = await websocket.recv() print (greeting) except websockets.exceptions.InvalidState: print (websocket.state) print ('Exit') Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Bitcoin2017 Geschrieben 13. Dezember 2017 Autor Teilen Geschrieben 13. Dezember 2017 Gibts eine Idee wo das Problem sein könnte? Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mahe80 Geschrieben 19. Dezember 2017 Teilen Geschrieben 19. Dezember 2017 Ich hab exakt das gleiche Problem. Die Websocket-Verbindung wird nach ca. 90 Sekunden vom Server mit einem Status 1006 beendet. Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Jokin Geschrieben 19. Dezember 2017 Teilen Geschrieben 19. Dezember 2017 Google: "Status 1006 " Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
mahe80 Geschrieben 19. Dezember 2017 Teilen Geschrieben 19. Dezember 2017 Das war natürlich das erste, was ich gesucht habe. Status 1006 sagt, dass die Verbindung ohne ein close frame geschlossen wurde. Das ist ja das Problem! Warum wird die Verbindung geschlossen? Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
eazy Geschrieben 31. Januar 2018 Teilen Geschrieben 31. Januar 2018 Moin, hab das gleiche Problem mit meiner PHP Implementierung. 86 Sekunden und der Server macht zu. Hat hier einer nen Tipp? Oder bleibt das Thema ein Rätsel? Einfach ne reconnect ist ja blöd, da fehlen mir mit Pech ja ein paar Bewegungen, außer ich mach den zweiten Socket ein paar Sekunden vorher auf und gleiche ab. Klingt dann halt irgendwie nach gebastel. Danke bye eazy Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
matthias.linden Geschrieben 1. Februar 2018 Teilen Geschrieben 1. Februar 2018 (bearbeitet) Zur Zusammenfassung: '"Websocket" ist in diesem Fall ein socket.io Server der neben websocket auch andere Möglichkeiten bietet um sich die Daten ausliefern zu lassen (Longpolling, etc.) Die Schnittstelle liefern über https eine URI aus, die websocket spricht Wenn man diese URI nutzt und sich mit dem websocket-framework der Wahl verbindet bricht die Verbindung nach ~90s ab und liefert keine Daten mehr Auch websocket-pings helfen nicht Bei mir hat es (in Python mit twisted als async-framework) funktioniert, wenn ich die gleiche https-Verbindung, mit der ich die URI abgefragt habe auf websocket upgrade, anstelle eine neue websocket-Verbindung mit der URI aufzubauen. Websocket baut auf http auf und verwendet einen upgrade-handshake um sich auf das Format der Daten zu verständigen. Insofern kann jede http Verbindung websocket-tauglich gemacht werden, wenn man die richtigen Pakete schickt. Die Abfrage liefert eine nonce und Reihe von Optionen. Wenn websocket dabei ist, kann man ein Upgrade anfordern. Die nonce wie in der Response, der websocket_key kann frei gewählt werden, muss aber gespeichert werden GET /socket.io/1/websocket/%s HTTP/1.1 %nonce Accept-Encoding: gzip, deflate, sdch Connection: Upgrade Upgrade: websocket Sec-WebSocket-Key: %s %websocket_key Sec-WebSocket-Version: 13 Man bekommt wenn alles gut geht eine Antwort mit "Status 101" "Switching Protocol" HTTP/1.1 101 Switching Protocols Accept-Encoding:gzip, deflate Connection:Upgrade Sec-WebSocket-Accept:LlV+ly6R1Mi9Jn+/1+p6ps5ZoqM= SHA1(websocket_key+Websocket_MAGIC) sollte gleich Sec-WebSocket-Accept sein. Ab jetzt liefert die Verbindung im Websocket-Format. Details dazu lassen sich googlen. 2Byte Status ::: Daten oder so. Die Heartbeats kann man mit bytearray([129,3])+bytes("2::") beantworten. Bearbeitet 1. Februar 2018 von matthias.linden Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
CosmoK Geschrieben 5. Februar 2018 Teilen Geschrieben 5. Februar 2018 @matthias.linden Vielen Dank für die ausführliche Erklärung! Ich bin leider noch Python-Neuling. Könntest Du vielleicht Deinen beispielhaften Python-Code zur Websocket-Abfrage hier hochladen/posten? Das wäre super nett, danke! Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren
Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können
Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!
Neues Benutzerkonto erstellenAnmelden
Du hast bereits ein Benutzerkonto? Melde Dich hier an.
Jetzt anmelden