Marcel Märtens dd581bc6c0 Participant closure was immeatiatly, even in case a new participant was connected, send a MSG and then dropped immeadiatly. ... The remote site should see it connect, be open for 1 single stream and read the message before it's notified that the participant is closed actually. This caused the faulure in one of our API tests (in lib, with client and server). Where it was possible that all messages were send and one side was dropped before the other side asked for the opened stream Also introduce better error detection in participant(and scheduler) by removing the std_async::Result and intruduce `Result<(),ParticipantError>` instead		2020-07-22 09:18:15 +02:00
..
api.rs	Participant closure was immeatiatly, even in case a new participant was connected, send a MSG and then dropped immeadiatly.	2020-07-22 09:18:15 +02:00
channel.rs	make prometheus optional in network and fix a panic in the server	2020-07-15 16:45:49 +02:00
lib.rs	make prometheus optional in network and fix a panic in the server	2020-07-15 16:45:49 +02:00
message.rs	fix a followup bug, after a protocol fail now Participant is closed, including all streams, so we get the stream errors.	2020-07-13 13:03:35 +02:00
metrics.rs	zests fix - capitalize first letter	2020-07-13 13:03:01 +02:00
participant.rs	Participant closure was immeatiatly, even in case a new participant was connected, send a MSG and then dropped immeadiatly.	2020-07-22 09:18:15 +02:00
prios.rs	make prometheus optional in network and fix a panic in the server	2020-07-15 16:45:49 +02:00
protocols.rs	make prometheus optional in network and fix a panic in the server	2020-07-15 16:45:49 +02:00
scheduler.rs	Participant closure was immeatiatly, even in case a new participant was connected, send a MSG and then dropped immeadiatly.	2020-07-22 09:18:15 +02:00
types.rs	make prometheus optional in network and fix a panic in the server	2020-07-15 16:45:49 +02:00