network-transport-tests- Unit tests for Network.Transport implementations

Safe HaskellNone




echoServer :: EndPoint -> IO ()Source

Server that echoes messages straight back to the origin endpoint.

ping :: EndPoint -> EndPointAddress -> Int -> ByteString -> IO ()Source

Ping client used in a few tests

testPingPong :: Transport -> Int -> IO ()Source

Basic ping test

testEndPoints :: Transport -> Int -> IO ()Source

Test that endpoints don't get confused

testCloseOneConnection :: Transport -> Int -> IO ()Source

Test that closing one connection does not close the other

testCloseOneDirection :: Transport -> Int -> IO ()Source

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 :: EndPoint -> Maybe Int -> Maybe Int -> IO [(ConnectionId, [[ByteString]])]Source

Collect events and order them by connection ID

testCloseReopen :: Transport -> Int -> IO ()Source

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.

testParallelConnects :: Transport -> Int -> IO ()Source

Test lots of parallel connection attempts

testSendAfterClose :: Transport -> Int -> IO ()Source

Test that sending on a closed connection gives an error

testCloseTwice :: Transport -> Int -> IO ()Source

Test that closing the same connection twice has no effect

testConnectToSelf :: Transport -> Int -> IO ()Source

Test that we can connect an endpoint to itself

testConnectToSelfTwice :: Transport -> Int -> IO ()Source

Test that we can connect an endpoint to itself multiple times

testCloseSelf :: IO (Either String Transport) -> IO ()Source

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

testCloseEndPoint :: Transport -> Int -> IO ()Source

Test various aspects of closeEndPoint

testConnectClosedEndPoint :: Transport -> IO ()Source

Remote node attempts to connect to a closed local endpoint

testExceptionOnReceive :: IO (Either String Transport) -> IO ()Source

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

testSendException :: IO (Either String Transport) -> IO ()Source

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

testKill :: IO (Either String Transport) -> Int -> IO ()Source

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.

testCrossing :: Transport -> Int -> IO ()Source

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