aiocoap.tokenmanager module

class aiocoap.tokenmanager.TokenManager(context)

Bases: aiocoap.interfaces.RequestInterface, aiocoap.interfaces.TokenManager

outgoing_requests = None

Unfinished outgoing requests (identified by token and remote)

incoming_requests = None

Unfinished incoming requests.

client_credentials

next_token()

Reserve and return a new Token for request.

dispatch_error(exception, remote)

process_request(request)

process_response(response)

request(request)

fill_or_recognize_remote(message)

shutdown()

class aiocoap.tokenmanager.PlumbingRequest(request, log)

Bases: object

Low-level meeting point between a request and a any responses that come back on it.

A single request message is placed in the PlumbingRequest at creation time. Any responses, as well as any exception happening in the course of processing, are passed back to the requester along the PlumbingRequest. A response can carry an indication of whether it is final; an exception always is.

This object is used both on the client side (where the Context on behalf of the application creates a PlumbingRequest and passes it to the network transports that send the request and fill in any responses) and on the server side (where the Context creates one for an incoming request and eventually lets the server implementation populate it with responses).

This currently follows a callback dispatch style. (It may be developed into something where only awaiting a response drives the proces, though).

Currently, the requester sets up the object, connects callbacks, and then passes the PlumbingRequest on to whatever creates the response.

The creator of responses is notified by the PlumbingRequest of a loss of interest in a response when there are no more callback handlers registered by registering an on_interest_end callback. As the response callbacks need to be already in place when the PlumbingRequest is passed on to the responder, the absence event callbacks is signalled by callign the callback immediately on registration.

To accurately model “loss of interest”, it is important to use the two-phase setup of first registering actual callbacks and then producing events and/or placing on_interest_end callbacks; this is not clearly expressed in type or state yet. (One possibility would be for the PlumbingRequest to carry a preparation boolean, and which prohibits event sending during preparation and is_interest=True callback creation afterwards).

class Event(message, exception, is_last)

Bases: tuple

exception

Alias for field number 1

is_last

Alias for field number 2

message

Alias for field number 0

poke()

Ask the responder for a life sign. It is up to the responder to ignore this (eg. because the responder is the library/application and can’t be just gone), to issue a generic transport-dependent ‘ping’ to see whether the connection is still alive, or to retransmit the request if it is an observation over an unreliable channel.

In any case, no status is reported directly to the poke, but if whatever the responder does fails, it will send an appropriate error message as a response.

on_event(callback, is_interest=True)

Call callback on any event. The callback must return True to be called again after an event. Callbacks must not produce new events or deregister unrelated event handlers.

If is_interest=False, the callback will not be counted toward the active callbacks, and will receive a (None, None, is_last=True) event eventually.

To unregister the handler, call the returned closure; this can trigger on_interest_end callbacks.

on_interest_end(callback)

Register a callback that will be called exactly once – either right now if there is not even a current indicated interest, or at a last event, or when no more interests are present

add_response(response, is_last=False)

add_exception(exception)