it does not make sense to cancel it, it does not do anything when the
sending queue is empty, and clients should not fill the send queue when
not connected anyway.
Otherwise we could end up reconnecting and getting some useful things
like the XML parser or other stuff removed afterwards.
Also, move 'session_end' before 'disconnected', it makes more sense that
way.
This is just a hotfix workaround for an underlying problem. The
`_connect_routine` code is "blocking" (in an async way) for
`connect_loop_wait` seconds, so that a fresh-started manual reconnect
will be silenty delayed. This code does the following changes:
1. It moves the delay to before the DNS resolution (with the exponential
back-off it might well be that the DNS records are changed while
slixmpp is waiting).
2. It adds a new event `reconnect_delay` that gets passed the number of
seconds it will delay before actually reconnecting
3. It resets the `connect_loop_wait` timer on a manual connect/reconnect
call to fix the interactive experience.
A *proper fix* would replace the sleep in `_connect_routine` with a
properly timered re-invocation of it, but I don't understand enough of
asyncio for pulling off that magic, and this is actually a proper
improvement. Also I tested this and it works!
The 'disconnected' event is normally fired from connection_lost(), which
is called by the connection code when the connection is lost after being
established. However, if the connection wasn't successfully established,
a manual /reconnect no-ops because it waits for the 'disconnected'
callback which never fires. This patch does two things:
1. Immediately fire a 'disconnected' event in disconnect() if there is
no transport.
2. Register the 'disconnected' event handler in reconnect() *before* it
can be fired.
This reverts commit 37bc1bb9b3bdc26b7f28b30406d1013f9b0f6ceb.
Confusion confusion. Mathieui thought this was a sleekxmpp thing when
it's actually been added not so long ago.
It does not make sense to have competing connection attempts, as the
XMLStream class is not designed for this. On slow and unpredictable
networks, it means we could have two c2s connections opened, leading to
mayhem.
This seems to be the same issue as:
https://dev.louiz.org/issues/3164
Using their suggested fix, if the DNS lookup doesn't return a port, use
the one passed in instead.
