# `node` — XMPP network nodes (clients, mostly)

This module contains functions to connect to an XMPP server, as well as maintaining the stream. In addition, a client class which completely manages a stream based on a presence setting is provided.

## Using XMPP

class `aioxmpp.``Client`(local_jid, security_layer, *, negotiation_timeout=datetime.timedelta(seconds=60), max_initial_attempts=4, override_peer=[], loop=None, logger=None)

  Base class to implement an XMPP client.

  Parameters:

  - local_jid (`JID`) – Jabber ID to connect as
  - security_layer (`SecurityLayer`) – Configuration for authentication and TLS
  - negotiation_timeout (`datetime.timedelta`) – Timeout for the individual stream negotiation steps (bounds initial connection time)
  - override_peer (sequence of connection option triples) – Connection options which take precedence over the standardised connection options
  - max_inital_attempts – Maximum number of initial connection attempts
  - loop (`asyncio.BaseEventLoop` or `None`) – Override the `asyncio` event loop to use
  - logger (`logging.Logger` or `None`) – Logger to use instead of the default logger

  These classes deal with managing the `StanzaStream` and the underlying `XMLStream` instances. The abstract client provides functionality for connecting the xmlstream as well as signals which indicate changes in the stream state.

  The security_layer is best created using the `aioxmpp.security_layer.make()` function and must provide authentication for the given local_jid.

  If loop is given, it must be a `asyncio.BaseEventLoop` instance. If it is not given, the current event loop is used.

  As a glue between the stanza stream and the XML stream, it also knows about stream management and performs stream management negotiation. It is specialized on client operations, which implies that it will try to keep the stream alive as long as wished by the client.

  The client will attempt to connect to the server(s) associated with the local_jid, using the prioritised override_peer setting or the standardised options for connecting (see `discover_connectors()`). The initial connection attempt must succeed within max_initial_attempts.

  If the connection breaks after the first connection attempt, the client will try to resume the connection transparently. If the server supports stream management (XEP-0198) with resumption, this is entirely transparent to all operations over the stream. If the stream is not resumable or the resumption fails and allow_implicit_reconnect is true, the application and services using the stream are notified about that. If, in that situation, allow_implicit_reconnect is false instead, the client stops with an error.

  The number of reconnection attempts is generally unbounded. The application is notified that the stream got interrupted with the `on_stream_suspended()` is emitted. After reconnection, `on_stream_established()` is emitted (possibly preceded by a `on_stream_destroyed()` emission if the stream failed to resume). If the application wishes to bound the time the stream tries to transparently reconnect, it should connect to the `on_stream_suspended()` signal and stop the stream as needed.

  The reconnection attempts are throttled using expenential backoff controlled by the `backoff_start`, `backoff_factor` and `backoff_cap` attributes.

  Note

  If max_initial_attempts is `None`, the stream will try indefinitly to connect to the server even if the connection has never succeeded yet. This is may mask problems with the configuration of the client itself, because the client cannot successfully distinguish permanent problems arising from the configuration (of the client or the server) from problems arising from transient problems such as network faliures.

  This may severely degrade usabilty, because the client is then stuck in a connect loop without any usable feedback. Setting a bound for the initial connection attempt is usually better, for interactive applications an upper bound of 1 might make most sense (possibly the interactive application may retry on its own if the user did not indicate that they wish to do so after a timeout). We’ll leave the UX considerations up to you.

  Changed in version 0.4: Since 0.4, support for legacy XMPP sessions has been implemented. Mainly for compatiblity with ejabberd.

  Changed in version 0.8: The amount of initial connection attempts is now bounded by max_initial_attempts. The `on_stream_suspended()` signal and the associated logic has been introduced.

  Controlling the client:

  `connected`(*, presence=<PresenceState>, **kwargs)

    Return a `node.UseConnected` context manager which does not modify the presence settings.

    The keyword arguments are passed to the `node.UseConnected` context manager constructor.

    New in version 0.8.

  `start`()

    Start the client. If it is already `running`, `RuntimeError` is raised.

    While the client is running, it will try to keep an XMPP connection open to the server associated with `local_jid`.

  `stop`()

    Stop the client. This sends a signal to the clients main task which makes it terminate.

    It may take some cycles through the event loop to stop the client task. To check whether the task has actually stopped, query `running`.

  `running`

    true if the client is currently running, false otherwise.

  `negotiation_timeout` = timedelta(seconds=60)

    The timeout applied to the connection process and the individual steps of negotiating the stream. See the negotiation_timeout argument to `connect_xmlstream()`.

  `override_peer`

    A sequence of triples `(host, port, connector)`, where host must be a host name or IP as string, port must be a port number and connector must be a `aioxmpp.connector.BaseConnctor` instance.

    These connection options are passed to `connect_xmlstream()` and thus take precedence over the options discovered using `discover_connectors()`.

    Note

    If Stream Management is used and the peer server provided a location to connect to on resumption, that location is preferred even over the options set here.

    New in version 0.6.

  `resumption_timeout` = None

    The maximum time as integer in seconds for which the server shall hold on to the session if the underlying transport breaks.

    This is only relevant if the server supports Stream Management and the server may ignore the request for a maximum timeout and/or impose its own maximum. After the stream has been negotiated, `StanzaStream.sm_max` holds the actual timeout announced by the server (may be `None` if the server did not specify a timeout).

    The default value of `None` does not request any specific timeout from the server and leaves it up to the server to decide.

    Setting a `resumption_timeout` of zero (0) disables resumption.

    New in version 0.9.

  Connection information:

  `established`

    true if the stream is currently established (as defined in `on_stream_established`) and false otherwise.

  `established_event`

    An `asyncio.Event` which indicates that the stream is established. A stream is valid after resource binding and before it has been destroyed.

    While this event is cleared, `enqueue()` fails with `ConnectionError` and `send()` blocks.

  `local_jid`

    The `JID` the client currently has. While the client is disconnected, which parts of the `local_jid` can be relied upon depends on the authentication mechanism used. For example, using anonymous authentication, the server dictates even the local part of the JID and it will change after a reconnect. For more common authentication schemes (such as normal password-based authentication), the localpart is usually chosen by the client.

    For interoperability with different authentication schemes, code must invalidate all copies of this attribute when a `on_stream_established()` or `on_stream_destroyed()` event is emitted.

    Writing this attribute is not allowed, as changing the JID introduces a lot of issues with respect to reusability of the stream. Instanciate a new `Client` if you need to change the bare part of the JID.

    Note

    Changing the resource between reconnects may be allowed later.

  `stream`

    The `StanzaStream` instance used by the node.

  `stream_features`

    An instance of `StreamFeatures`. This is the most-recently received stream features information (the one received right before resource binding).

    While no stream has been established yet, this is `None`. During transparent re-negotiation, that information may be obsolete. However, when `before_stream_established` fires, the information is up-to-date.

  Sending stanzas:

  coroutine `send`(stanza, *, timeout=None, cb=None)

    Send a stanza.

    Parameters:

    - stanza (`IQ`, `Presence` or `Message`) – Stanza to send
    - timeout (`Real` or `None`) – Maximum time in seconds to wait for an IQ response, or `None` to disable the timeout.
    - cb – Optional callback which is called synchronously when the reply is received (IQ requests only!)

    Raises:

    - OSError – if the underlying XML stream fails and stream management is not disabled.
    - aioxmpp.stream.DestructionRequested – if the stream is closed while sending the stanza or waiting for a response.
    - aioxmpp.errors.XMPPError – if an error IQ response is received
    - aioxmpp.errors.ErroneousStanza – if the IQ response could not be parsed
    - ValueError – if cb is given and stanza is not an IQ request.

    Returns: | IQ response `payload` or `None`

    Send the stanza and wait for it to be sent. If the stanza is an IQ request, the response is awaited and the `payload` of the response is returned.

    If the stream is currently not ready, this method blocks until the stream is ready to send payload stanzas. Note that this may be before initial presence has been sent. To synchronise with that type of events, use the appropriate signals.

    The timeout as well as any of the exception cases referring to a “response” do not apply for IQ response stanzas, message stanzas or presence stanzas sent with this method, as this method only waits for a reply if an IQ request stanza is being sent.

    If stanza is an IQ request and the response is not received within timeout seconds, `TimeoutError` (not `asyncio.TimeoutError`!) is raised.

    If cb is given, stanza must be an IQ request (otherwise, `ValueError` is raised before the stanza is sent). It must be a callable returning an awaitable. It receives the response stanza as first and only argument. The returned awaitable is awaited by `send()` and the result is returned instead of the original payload. cb is called synchronously from the stream handling loop when the response is received, so it can benefit from the strong ordering guarantees given by XMPP XML Streams.

    The cb may also return `None`, in which case `send()` will simply return the IQ payload as if cb was not given. Since the return value of coroutine functions is awaitable, it is valid and supported to pass a coroutine function as cb.

    Warning

    Remember that it is an implementation detail of the event loop when a coroutine is scheduled after it awaited an awaitable; this implies that if the caller of `send()` is merely awaiting the `send()` coroutine, the strong ordering guarantees of XMPP XML Streams are lost.

    To regain those, use the cb argument.

    Note

    For the sake of readability, unless you really need the strong ordering guarantees, avoid the use of the cb argument. Avoid using a coroutine function unless you really need to.

    Changed in version 0.10:

    - This method now waits until the stream is ready to send stanza¸ payloads.

    - This method was moved from `aioxmpp.stream.StanzaStream.send()`.

    Changed in version 0.9: The cb argument was added.

    New in version 0.8.

  `enqueue`(stanza, **kwargs)

    Put a stanza in the internal transmission queue and return a token to track it.

    Parameters:

    - stanza (`IQ`, `Message` or `Presence`) – Stanza to send
    - kwargs – see `StanzaToken`

    Raises: | ConnectionError – if the stream is not `established` yet.
    Returns: | token which tracks the stanza
    Return type: | `StanzaToken`

    The stanza is enqueued in the active queue for transmission and will be sent on the next opportunity. The relative ordering of stanzas enqueued is always preserved.

    Return a fresh `StanzaToken` instance which traks the progress of the transmission of the stanza. The kwargs are forwarded to the `StanzaToken` constructor.

    This method calls `autoset_id()` on the stanza automatically.

    See also

    `send()`
      for a more high-level way to send stanzas.

    Changed in version 0.10: This method has been moved from `aioxmpp.stream.StanzaStream.enqueue()`.

  Configuration of exponential backoff for reconnects:

  `backoff_start` = timedelta(1)

    When an underlying XML stream fails due to connectivity issues (generic `OSError` raised), exponential backoff takes place before attempting to reconnect.

    The initial time to wait before reconnecting is described by `backoff_start`.

  `backoff_factor` = 1.2

    Each subsequent time a connection fails, the previous backoff time is multiplied with `backoff_factor`.

  `backoff_cap` = timedelta(60)

    The backoff time is capped to `backoff_cap`, to avoid having unrealistically high values.

  Signals:

  signal `on_failure`(err)

    This signal is fired when the client fails and stops.

  coroutine signal `before_stream_established`()

    This coroutine signal is executed right before `on_stream_established()` fires.

  signal `on_stopped`()

    Fires when the client stops gracefully. This is the counterpart to `on_failure()`.

  signal `on_stream_established`()

    When the stream is established and resource binding took place, this event is fired. It means that the stream can now be used for XMPP interactions.

  signal `on_stream_suspended`(reason)

    The stream has been suspened due to a connection failure.

    Parameters: | reason (`Exception`) – The exception which terminated the stream.

    This signal may be immediately followed by a `on_stream_destroyed()`, if the stream did not support stream resumption. Otherwise, a new connection is attempted transparently.

    In general, this signal exists solely for informational purposes. It can be used to drive a user interface which indicates that messages may be delivered with delay, because the underlying network is transiently interrupted.

    `on_stream_suspended()` is not emitted if the stream was stopped on user request.

    Only `on_stream_destroyed()` indicates that state was actually lost and that others most likely see or saw an unavailable presence broadcast for the resource.

    New in version 0.8.

  signal `on_stream_destroyed`(reason=None)

    This is called whenever a stream is destroyed. The conditions for this are the same as for `aioxmpp.stream.StanzaStream.on_stream_destroyed`.

    Parameters: | reason (`Exception`) – An optional exception which indicates the reason for the destruction of the stream.

    This event can be used to know when to discard all state about the XMPP connection, such as roster information. Services implemented in `aioxmpp` generally subscribe to this signal to discard cached state.

    reason is optional. It is given if there is has been a specific exception which describes the cause for the stream destruction, such as a `ConnectionError`.

    Changed in version 0.8: The reason argument was added.

  Services:

  `summon`(class_)

    Summon a `Service` for the client.

    If the class_ has already been summoned for the client, it’s instance is returned.

    Otherwise, all requirements for the class are first summoned (if they are not there already). Afterwards, the class itself is summoned and the instance is returned.

  Miscellaneous:

  `logger`

    The `logging.Logger` instance which is used by the `Client`. This is the logger passed to the constructor or a logger derived from the fully qualified name of the class.

    New in version 0.6: The `logger` attribute was added.

class `aioxmpp.``PresenceManagedClient`(jid, security_layer, **kwargs)

  Client whose connection is controlled by its configured presence.

  See also

  `Client`
    for a description of the arguments.

  The presence is set using `presence` or the `PresenceServer` service. If the set presence is an available presence, the client is started (if it is not already running). If the set presence is an unavailable presence, the unavailable presence is broadcast and the client is stopped.

  While the start/stop interfaces of `Client` are still available, using them may interfere with the behaviour of the presence automagic.

  The initial presence is set to unavailable, thus, the client will not connect immediately.

  `presence`

    Control or query the current presence state (see `PresenceState`) of the client. Note that when reading, the property only returns the “set” value, not the actual value known to the server (and others). This may differ if the connection is still being established.

    See also

    Setting the presence state using `presence` clears the status of the presence. To set the status and state at once, use `set_presence()`.

    Upon setting this attribute, the `PresenceManagedClient` will do whatever neccessary to achieve the given presence. If the presence is an available presence, the client will attempt to connect to the server. If the presence is unavailable and the client is currently connected, it will disconnect.

    Instead of setting the presence to unavailable, `stop()` can also be called. The `presence` attribute is not affected by calls to `start()` or `stop()`.

  `set_presence`(state, status)

    Set the presence state and status on the client. This has the same effects as writing state to `presence`, but the status of the presence is also set at the same time.

    status must be either a string or something which can be passed to `dict`. If it is a string, the string is wrapped in a `{None: status}` dictionary. Otherwise, the dictionary is set as the `status` attribute of the presence stanza. It must map `aioxmpp.structs.LanguageTag` instances to strings.

    The status is the text shown alongside the state (indicating availability such as away, do not disturb and free to chat).

  `connected`(**kwargs)

    Return a `node.UseConnected` context manager which sets the presence to available.

    The keyword arguments are passed to the `node.UseConnected` context manager constructor.

    Note

    In contrast to the same method on `Client`, this method implies setting an available presence.

    New in version 0.6.

  Signals:

  `on_presence_sent`

    The event is fired after `Client.on_stream_established()` and after the current presence has been sent to the server as initial presence.

  Changed in version 0.8: Since 0.8, the `PresenceManagedClient` is implemented on top of `PresenceServer`. Changing the presence via the `PresenceServer` has the same effect as writing `presence` or calling `set_presence()`.

class `aioxmpp.node.``AbstractClient`

  Alias of `Client`.

  Deprecated since version 0.8: The alias will be removed in 1.0.

## Connecting streams low-level

coroutine `aioxmpp.node.``discover_connectors`(domain: str, loop=None, logger=<Logger aioxmpp.node (WARNING)>)

  Discover all connection options for a domain, in descending order of preference.

  This coroutine returns options discovered from SRV records, or if none are found, the generic option using the domain name and the default XMPP client port.

  Each option is represented by a triple `(host, port, connector)`. connector is a `aioxmpp.connector.BaseConnector` instance which is suitable to connect to the given host and port.

  logger is the logger used by the function.

  The following sources are supported:

  - RFC 6120 SRV records. One option is returned per SRV record.

    If one of the SRV records points to the root name (`.`), `ValueError` is raised (the domain specifically said that XMPP is not supported here).

  - XEP-0368 SRV records. One option is returned per SRV record.

  - RFC 6120 fallback process (only if no SRV records are found). One option is returned for the host name with the default XMPP client port.

  The options discovered from SRV records are mixed together, ordered by priority and then within priorities are shuffled according to their weight. Thus, if there are multiple records of equal priority, the result of the function is not deterministic.

  New in version 0.6.

coroutine `aioxmpp.node.``connect_xmlstream`(jid, metadata, negotiation_timeout=60.0, override_peer=[], loop=None, logger=<Logger aioxmpp.node (WARNING)>)

  Prepare and connect a `aioxmpp.protocol.XMLStream` to a server responsible for the given jid and authenticate against that server using the SASL mechansims described in metadata.

  Parameters:

  - jid (`aioxmpp.JID`) – Address of the user for which the connection is made.
  - metadata (`SecurityLayer`) – Connection metadata for configuring the TLS usage.
  - negotiation_timeout (`float` in seconds) – Timeout for each individual negotiation step.
  - override_peer (sequence of (`str`, `int`, `BaseConnector`) triples) – Sequence of connection options which take precedence over normal discovery methods.
  - loop (`asyncio.BaseEventLoop`) – asyncio event loop to use (defaults to current)
  - logger (`logging.Logger`) – Logger to use (defaults to module-wide logger)

  Raises:

  - ValueError – if the domain from the jid announces that XMPP is not supported at all.
  - aioxmpp.errors.TLSFailure – if all connection attempts fail and one of them is a `TLSFailure`.
  - aioxmpp.errors.MultiOSError – if all connection attempts fail.

  Returns: | Transport, XML stream and the current stream features
  Return type: | tuple of (`asyncio.BaseTransport`, `XMLStream`, `StreamFeatures`)

  The part of the metadata specifying the use of TLS is applied. If the security layer does not mandate TLS, the resulting XML stream may not be using TLS. TLS is used whenever possible.

  The connection options in override_peer are tried before any standardised discovery of connection options is made. Only if all of them fail, automatic discovery of connection options is performed.

  loop may be a `asyncio.BaseEventLoop` to use. Defaults to the current event loop.

  If the domain from the jid announces that XMPP is not supported at all, `ValueError` is raised. If no options are returned from `discover_connectors()` and override_peer is empty, `ValueError` is raised, too.

  If all connection attempts fail, `aioxmpp.errors.MultiOSError` is raised. The error contains one exception for each of the options discovered as well as the elements from override_peer in the order they were tried.

  A TLS problem is treated like any other connection problem and the other connection options are considered. However, if all connection options fail and the set of encountered errors includes a TLS error, the TLS error is re-raised instead of raising a `aioxmpp.errors.MultiOSError`.

  Return a triple `(transport, xmlstream, features)`. transport the underlying `asyncio.Transport` which is used for the xmlstream `XMLStream` instance. features is the `aioxmpp.nonza.StreamFeatures` instance describing the features of the stream.

  New in version 0.6.

  Changed in version 0.8: The explicit raising of TLS errors has been introduced. Before, TLS errors were treated like any other connection error, possibly masking configuration problems.

## Utilities

class `aioxmpp.node.``UseConnected`(client, *, timeout=None, presence=<PresenceState available>)

  Asynchronous context manager which connects and disconnects a `Client`.

  Parameters:

  - client (`Client`) – The client to manage
  - timeout (`datetime.timedelta` or `None`) – Limit on the time it may take to start the client
  - presence (`PresenceState`) – Presence state to set on the client (deprecated)

  When the asynchronous context is entered (see PEP 492), the client is connected. This blocks until the client has finished connecting and the stream is established. If the client takes longer than timeout to connect, `TimeoutError` is raised and the client is stopped. The context manager returns the `stream` of the client.

  When the context is exited, the client is disconnected and the context manager waits for the client to cleanly shut down the stream.

  If the client is already connected when the context is entered, the connection is re-used and not shut down when the context is entered, but leaving the context still disconnects the client.

  If the presence refers to an available presence, the `PresenceServer` is `summon()`-ed on the client. The presence is set using `set_presence()` (clearing the `status` and resetting `priority` to 0) before the client is connected. If the client is already connected, the presence is set when the context is entered.

  Deprecated since version 0.8: The use of the presence argument is deprecated. The deprecation will happen in two phases:

  1. Until (but not including the release of) 1.0, passing a presence state which refers to an available presence will emit `DeprecationWarning`. This includes the default of the argument, so unless an unavailable presence state is passed explicitly, all uses of `UseConnected` emit that warning.
  2. Starting with 1.0, passing an available presence will raise `ValueError`.
  3. Starting with a to-be-determined release after 1.0, passing the presence argument at all will raise `TypeError`.

  Users which previously used the presence argument should use the `PresenceServer` service on the client and set the presence before using the context manager instead.

  `presence`

    See the description of the presence argument.

    Deprecated since version 0.8: Using this attribute (for reading or writing) is deprecated and emits a deprecation warning.

  `timeout`

    See the description of the timeout argument.

    Deprecated since version 0.8: Using this attribute (for reading or writing) is deprecated and emits a deprecation warning.