Ein Server in ein paar Zeilen

interop.py hat den Client der Bibliothek auf den Server aus Kapitel 5 gerichtet. Diese Lektion dreht das um: Der Server wird zu dem der Bibliothek. In Kapitel 5 hat serve_conversation Frames gelesen, Pings beantwortet, Echos gesendet, gezählt und den Schließ-Handshake ausgeführt, nachdem serve_handshake das Upgrade beantwortet hatte. Mit der Bibliothek passt der Teil, bei dem es um das Echo geht, in einen Handler von etwa sechs Zeilen.

Ein Handler und seine Verbindung

Ein Handler ist eine Funktion, die du schreibst und die die Bibliothek aufruft. Sie nimmt ein Argument, die Verbindung zu einem Client, und verwendet darauf ein paar Dinge:

• connection.recv(timeout=...) wartet höchstens so viele Sekunden auf die nächste Nachricht und gibt sie zurück: einen str für eine Textnachricht, bytes für eine binäre. Wenn nichts rechtzeitig ankommt, löst es TimeoutError aus.

• connection.send(message) sendet eine Nachricht: einen str als Text, bytes als binär.

• connection.close(code, reason) sendet einen Close-Frame mit diesem Code und Grund und führt den Schließ-Handshake aus.

• connection.request.path ist der Pfad, nach dem der Client gefragt hat, etwa /echo. Spätere Kapitel verwenden ihn; dieses nicht.

Alles andere erledigt die Bibliothek. Für jeden Client, der sich verbindet, führt sie den Handshake aus und ruft dann deinen Handler in einem eigenen Thread auf: das Muster mit einem Thread pro Verbindung aus Networks with Python, Kapitel 9. Wenn der Handler zurückkehrt, schließt die Bibliothek die Verbindung mit 1000, falls der Handler sie nicht schon geschlossen hat.

echo_handler(connection) ist die Echo-Schleife aus Kapitel 5 ohne die Infrastruktur. Solange weniger als MAX_MESSAGES Nachrichten als Echo zurückgesendet wurden, lies eine mit connection.recv(timeout=WAIT) und sende sie mit connection.send direkt zurück. Wenn du den Wert unverändert sendest, behält er seinen Typ, also geht Text als Text zurück und binär als binär, die Entscheidung, die server_reply mit Opcodes getroffen hat. Schließe nach der Schleife mit connection.close(1000, "message limit reached"). WAIT und MAX_MESSAGES stehen bereits oben in echo_library.py: 2 Sekunden und 10 Nachrichten.

Bedienen

run_echo(talk, *, serve=serve) bedient den Handler für ein Gespräch und übergibt den Port an talk, eine Funktion, die den Client spielt. Sie beginnt so:

with serve(echo_handler, "127.0.0.1", 0) as server:
    port = server.socket.getsockname()[1]

serve aus websockets.sync.server bindet und lauscht, wie socket.create_server, und gibt ein Server-Objekt zurück. Übergib echo_handler selbst, ohne es aufzurufen: Die Bibliothek ruft es auf, einmal pro Verbindung. Port 0 lässt das System einen freien Port wählen, und server.socket ist der lauschende Socket, also liest getsockname()[1] den Port so, wie du es in Networks getan hast.

Noch wird nichts bedient. server.serve_forever() nimmt Verbindungen an und startet für jede einen Handler-Thread, und es kehrt erst zurück, wenn der Server heruntergefahren wird. Also braucht es einen eigenen Thread: Erzeuge threading.Thread(target=server.serve_forever), wobei du die Methode übergibst, ohne sie aufzurufen, und starte ihn, bevor du talk(port) aufrufst.

Wenn der with-Block endet, aus welchem Grund auch immer, ruft das Server-Objekt shutdown() auf. Das schließt den lauschenden Socket, schließt jede noch offene Verbindung mit 1001 und lässt serve_forever zurückkehren. Führe nach dem Block den join des Threads mit timeout=WAIT aus und gib zurück, was talk zurückgegeben hat.

Der Parameter serve=serve ist eine Nahtstelle, wie connect= in Networks with Python: run_echo verwendet das serve der Bibliothek, außer ein Aufrufer übergibt ein anderes, und Submit übergibt einen Stellvertreter, der aufzeichnet, was dein Code damit macht.

Ein Gespräch mit der Bibliothek verwendet mehr Threads als deines. Bei einer lokalen Zählung lief ein Gespräch mit dem Server und dem Client der Bibliothek in einem Prozess mit sieben Threads, und mit fünf, als die Keepalive-Pings der Bibliothek abgeschaltet waren; Kapitel 8 behandelt diese Pings. Die Zahl hängt davon ab, wann du zählst, und deshalb zählt nichts in diesem Kurs Threads. Alle enden, wenn das Gespräch schließt und der Server herunterfährt.

Was weg ist

Leg echo_handler neben den Server aus Kapitel 5. Der Handshake ist weg: kein serve_handshake, kein check_upgrade, kein accept_value. Das Demaskieren ist weg, und der Pong auch: Die Bibliothek beantwortet jeden Ping, sobald er ankommt, und recv gibt dir immer nur Nachrichten. Auch der Schließ-Handshake ist weg: Wenn der Client einen Close sendet, beantwortet die Bibliothek ihn, die Arbeit, die dein close_frame und wait_for_close erledigt haben. Was bleibt, ist der Teil, der dieses Programm betrifft: wie viele Nachrichten, was zurückgesendet wird, wann geschlossen wird und mit welchem Code.

Bevor du auf Run klickst

Run gibt auf der Standardfehlerausgabe einen Block von etwa zehn Zeilen aus, der wie ein Absturz aussieht. In dieser Lektion ist das zu erwarten, und hier ist der Grund. Der Client aus Kapitel 5 sendet seine drei Nachrichten und schließt dann mit 1000 und dem Grund done. Dein Handler ist zurück in recv und wartet auf eine vierte Nachricht, und recv löst stattdessen ConnectionClosedOK aus. Die Ausnahme verlässt echo_handler, und die Bibliothek protokolliert sie. Der Block beginnt mit der Zeile connection handler failed, setzt sich mit einem Traceback fort, dessen Dateipfade sich von Rechner zu Rechner unterscheiden, und endet mit dieser Zeile:

websockets.exceptions.ConnectionClosedOK: received 1000 (OK) done; then sent 1000 (OK) done

Diese letzte Zeile sagt, dass die Verbindung trotzdem sauber geschlossen wurde: Die Bibliothek hat den Close des Clients empfangen und denselben Close zurückgesendet. Submit akzeptiert in dieser Lektion einen Handler, der diese Ausnahme entkommen lässt, und Lektion 4 fängt sie ab, sodass der Block verschwindet.

Klicke jetzt auf Run. Der Abschnitt zu Lektion 2 lässt den Client des Kurses aus Kapitel 5, von Hand gebaut, gegen deinen Bibliotheks-Server laufen. Eine fertige Version, auf der Website ausgeführt, hat Folgendes ausgegeben:

Lesson 2: your library server, the Chapter 5 client
{'echoes': ['hello', 'café ✓', 'third message'], 'code': 1000}

Der handgebaute Client hat gepingt und seinen Pong bekommen, drei Nachrichten gesendet, drei Echos bekommen und mit 1000 geschlossen; die Bibliothek hat jeden Frame beantwortet. Die späteren Abschnitte sagen noch “not written yet”. Klicke dann auf Submit.

Wenn dich die Threads verwirren, frag Monty:

Warum braucht serve_forever einen eigenen Thread, wenn die Bibliothek schon für jeden Handler einen Thread startet?

Der Server spricht mit einem handgebauten Client. In der nächsten Lektion wandert auch die Clientseite in die Bibliothek.