fix async_recv and double block_on panic on Network::drop and participant::drop
include Cargo.lock from all examples
Found a bug on imbris runners with doc tests of `stream::send` and `stream::recv`
As neither a backtrace, nor tracing on runners in the doc tests seems to help, i disable them and add them as unit tests
- switch `listen` to async in oder to verify if the bind was successful
- Introduce the following examples
- network speed
- chat
- fileshare
- add additional tests
- fix dropping stream before last messages can be handled bug, when dropping a stream, BParticipant will wait for prio to be empty before dropping the stream and sending the signal
- correct closing of stream and participant
- move tcp to protocols and create udp front and backend
- tracing and fixing a bug that is caused by not waiting for configuration after receiving a frame
- fix a bug in network-speed, but there is still a bug if trace=warn after 2.000.000 messages the server doesnt get that client has shut down and seems to lock somewhere. hard to reproduce
open tasks
[ ] verify UDP works correctly, especcially the connect!
[ ] implements UDP shutdown correctly, the one created in connect!
[ ] unify logging
[ ] fill metrics
[ ] fix dropping stream before last messages can be handled bug
[ ] add documentation
[ ] add benchmarks
[ ] remove async_serde???
[ ] add mpsc
- introduce a loadtest, for tcp messages
- cleanup api
- added a unittest
- prepared a handshake message, which will in next commits get removed again
- experimental mio worker merges
- using uuid for participant id
- soil production (currently disabled).
- debris flow erosion (combined with regular stream power law).
- flow computation using multiple receivers.
- filling strategy during drainage network calculations.
Also tweaks a variety of other aspects of erosion.
This was necessary because Cargo recently deprecated the "overrides"
keyword in favor of "package", and Criterion changed its interface.
This commit also now lists more configurable keys, so if they aren't set
to their defaults the user will be able to find them. This includes the
roll key, which wasn't listed earlier and is different on Windows and
Mac. It does *not* include the respawn key because that key is already
shown when you die.
Currently we only do this when no players are in range of the chunk. We
also send the first client who posted the chunk a message indicating
that it's canceled, the hope being that this will be a performance win
in single player mode since you don't have to wait three seconds to
realize that the server won't generate the chunk for you.
We now check an atomic flag for every column sample in a chunk. We
could probably do this less frequently, but since it's a relaxed load it
has essentially no performance impact on Intel architectures.
