- restructure message classes in sealed traits according to message flow
direction and include confirmed/unconfirmed status in the type
- add GetAddress query for obtaining the remote transport address of
another test participant
- add reconnects to Player
- add small DSL with runOn(node...), ifNode(node...)(<true>)(<false>)
and node(<node>):ActorPath
- rewrite TestConductorSpec to use that DSL and run within a single test
procedure instead of separate NodeX classes
- hook up that test into current multi-jvm infrastructure temporarily
for testing (will use Björn’s new remote-multi-jvm stuff later)
- the Controller is started with the required initial number of
participants
- if that is >0, it will hold off sending Done to the clients until that
number has connected, then set it to zero
- if that is <=0, send Done back immediately upon connect
- split only right before send (if necessary)
- do not reschedule Tick if that has already been done, because the head
of the queue does not change so the old data are still correct
- make test a bit less fickle wrt. timing
- will keep track of theoretical packet boundaries and send on timer
tick or send request according to actual time
- will split packets if calculated release time is >100ms into the
future (configurable) to simulate proper trickling
- rework socket pipeline to transform protobuf into case classes and
back
- introduce NetworkOp messages for that purpose
- make API asynchronous (because it is, really) and add Done
notification for all server operations; enter(...) is still
synchronous, because that is its only purpose in life
- factor out mkPipeline in NettyRemoteTransport, enabling the very slick
TestConductorTransport (essentially a one-liner)
- switch NetworkFailureInjector from Channel{Up,Down}streamHandler to
subclassing SimpleChannelHandler, because otherwise deadlocks
occurred, not sure why (but SCH is the recommended way from the netty
docs, so there may well be a reason)
- make start-up synchronous and explicit for client and server
- server can be queried for actual port, client requires explicit port
- simple multi-jvm-test for verification of TestConductor barriers
- it compiles
- server side ("Conductor") functions almost there
- client side ("Player") sketched, but missing network failures
- no internal failure handling whatsoever, waiting for Project DeathWatch
- not yet possible to shutdown, need to kill VM
- next step is to hook into the NettyRemoteSupport for failure injection
