Lezen hoe een verbinding eindigde

De handler uit les 2 echoot correct, en elk gesprek dat hij bedient, eindigt nog steeds in een traceback. Lees het blok dat Run afdrukte: recv wierp ConnectionClosedOK op omdat de client als eerste sloot, niets in echo_handler ving het, dus de exception verliet de handler en de bibliotheek logde hem als connection handler failed. De verbinding zelf sloot netjes, zoals de laatste regel van het blok zei. Een client die sluit, is het normale einde van een gesprek, dus de handler moet daar zijn lus beëindigen. Deze les laat hem dat doen, en gebruikt daarna dezelfde exceptions om te melden hoe een gesprek eindigde.

OK en Error

Zodra een verbinding gesloten is, werpt elke latere recv en send erop een exception uit websockets.exceptions op. Welke hangt af van hoe de verbinding eindigde:

• ConnectionClosedOK als er een close-frame elke kant op ging en beide 1000, 1001 of helemaal geen code droegen (een lege close, die wordt gemeld als 1005);

• ConnectionClosedError in elk ander geval: een close met een andere code, zoals 1008, of een verbinding die eindigde zonder enig close-frame.

Die verdeling is de eigen keuze van de bibliotheek van wat als normaal einde telt, geen regel in RFC 6455. Beide klassen zijn soorten ConnectionClosed, de naam die echo_library.py al importeert. Een except-clausule die een klasse noemt, vangt ook elke exception die een soort van die klasse is, dus except ConnectionClosed: vangt allebei.

Wat er aankwam

Elk van deze exceptions draagt de close-frames. Noem de exception in de except-regel om ze te lezen:

try:
    connection.recv(timeout=WAIT)
except ConnectionClosed as exc:
    print(exc.rcvd)

exc.rcvd is het close-frame dat van de peer aankwam, met .code en .reason, en exc.sent is het frame dat deze kant stuurde. Elk van beide kan None zijn. Als exc.rcvd is None, kwam er geen close-frame aan: de TCP-verbinding eindigde zonder. Hoofdstuk 5 meldde dat geval als 1006, de code die nooit wordt verstuurd en alleen ooit een verbinding meldt die eindigde zonder close-frame, en describe_close doet hetzelfde.

describe_close(exc) controleert dus eerst exc.rcvd is None en geeft dan {"code": 1006, "reason": ""} terug. Anders geeft het de code en reden van exc.rcvd terug in dezelfde soort dict. Gebruik is None voor de controle, zoals je bij elke test op None zou doen.

Oudere code leest exc.code. Dat werkt nog in de versie die je vastpinde, maar het geeft een DeprecationWarning die naar rcvd.code verwijst, dus lees het close-frame via rcvd.

Bewaak send ook

recv is niet de enige aanroep die de verbinding gesloten kan aantreffen. De client kan sluiten nadat je recv terugkeerde en voordat je send draait; dan werpt send ConnectionClosedOK op. De try dekt dus beide regels van de lusbody:

try:
    message = connection.recv(timeout=WAIT)
    connection.send(message)
except ConnectionClosed:
    return

Het andere einde is een client die niets zegt. Als er binnen WAIT geen bericht aankomt, werpt recv de ingebouwde TimeoutError van Python op. Een client die 2 seconden niets heeft gestuurd, wacht nergens op van deze server, dus sluit hem zelf, met 1000 en een reden zoals "no message arrived in time", en keer terug. Geef de try een tweede clausule, except TimeoutError:, die dat doet.

Je opdracht

In echo_library.py:

1. schrijf describe_close(exc): {"code": 1006, "reason": ""} als exc.rcvd is None, en anders de code en reden uit exc.rcvd;

2. maak echo_handler af: zet binnen de lus recv en send in een try; keer bij ConnectionClosed terug; roep bij TimeoutError connection.close(1000, "no message arrived in time") aan en keer terug. De limiet en de laatste close na MAX_MESSAGES blijven zoals ze zijn.

Run

Druk op Run. Standaardfout blijft deze keer leeg: geen blok connection handler failed. Drie nieuwe secties maken verbinding met de client van de bibliotheek, lezen totdat de verbinding gesloten is, en drukken de klassenaam van de exception af en wat je describe_close ervan maakte. Een afgewerkte versie, gedraaid op de site, drukte af:

Lesson 4: you close
ConnectionClosedOK, {'code': 1000, 'reason': 'done'}
Lesson 4: the server closes with 1008
ConnectionClosedError, {'code': 1008, 'reason': 'this path is closed'}
Lesson 4: the server vanishes
ConnectionClosedError, {'code': 1006, 'reason': ''}

In de eerste sluit de client met 1000 en done, en de server antwoordt met dezelfde close, dus beide frames dragen 1000: OK. In de tweede sluit de handler van een bibliotheekserver meteen met 1008, dus het einde is een Error, en rcvd bevat de code en reden van de server. In de derde beantwoordt een server die met de hand is gebouwd uit serve_handshake van hoofdstuk 2 de upgrade met een 101 en sluit daarna de TCP-verbinding zonder close-frame: een Error met rcvd op None, wat je functie meldt als 1006. Lees ending en read_the_ending in library_demo.py om te zien hoe elk ervan tot stand komt. Druk daarna op Submit.

Je handler is een handvol regels, en je client een paar meer. De volgende les legt ze naast de functies die je in hoofdstuk 2 tot en met 5 schreef en benoemt wat de bibliotheek doet dat die nooit deden.