Network.Transport.Tests

Documentation

echoServer :: EndPoint -> IO ()

Server that echoes messages straight back to the origin endpoint.

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

Ping client used in a few tests

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

Basic ping test

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

Test that endpoints don't get confused

testConnections :: Transport -> Int -> IO ()

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

Test that closing one connection does not close the other

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

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]])]

Collect events and order them by connection ID

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

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 ()

Test lots of parallel connection attempts

testSelfSend :: Transport -> IO ()

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

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

Test that sending on a closed connection gives an error

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

Test that closing the same connection twice has no effect

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

Test that we can connect an endpoint to itself

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

Test that we can connect an endpoint to itself multiple times

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

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

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

Test various aspects of closeEndPoint

testCloseTransport :: IO (Either String Transport) -> IO ()

testConnectClosedEndPoint :: Transport -> IO ()

Remote node attempts to connect to a closed local endpoint

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

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 ()

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

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

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 ()

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

testTransport :: IO (Either String Transport) -> IO ()

testStreams :: Eq a => [a] -> [[a]] -> Bool