Documentation

Server that echoes messages straight back to the origin endpoint.

Ping client used in a few tests

Basic ping test

Test that endpoints don't get confused

Test that closing one connection does not close the other

Test that if A connects to B and B connects to A, B can still send to A after A closes its connection to B (for instance, in the TCP transport, the socket pair connecting A and B should not yet be closed).

Collect events and order them by connection ID

Open connection, close it, then reopen it (In the TCP transport this means the socket will be closed, then reopened)

Note that B cannot expect to receive all of A's messages on the first connection before receiving the messages on the second connection. What might (and sometimes does) happen is that finishes sending all of its messages on the first connection (in the TCP transport, the first socket pair) while B is behind on reading _from_ this connection (socket pair) -- the messages are "in transit" on the network (these tests are done on localhost, so there are in some OS buffer). Then when A opens the second connection (socket pair) B will spawn a new thread for this connection, and hence might start interleaving messages from the first and second connection.

This is correct behaviour, however: the transport API guarantees reliability and ordering _per connection_, but not _across_ connections.

Test lots of parallel connection attempts

Test that sending an error to self gives an error in the sender

Test that sending on a closed connection gives an error

Test that closing the same connection twice has no effect

Test that we can connect an endpoint to itself

Test that we can connect an endpoint to itself multiple times

Test that we self-connections no longer work once we close our endpoint or our transport

Test various aspects of closeEndPoint

Remote node attempts to connect to a closed local endpoint

We should receive an exception when doing a receive after we have been notified that an endpoint has been closed

Test what happens when the argument to send is an exceptional value

If threads get killed while executing a connect, send, or close, this should not affect other threads.

The intention of this test is to see what happens when a asynchronous exception happes _while executing a send_. This is exceedingly difficult to guarantee, however. Hence we run a large number of tests and insert random thread delays -- and even then it might not happen. Moreover, it will only happen when we run on multiple cores.

Set up conditions with a high likelyhood of "crossing" (for transports that multiplex lightweight connections across heavyweight connections)