Wrap tokio channels & Information Package Def

[191220029]

• Channel definition and unified implementaion of send & recv. The external definition of connections #72
• Def of information package (use Content in the old ver.). Encapsulation of processes and information packets #71

[kyrias]

This duplicates the actual method documentation.

[191220029]

I will remove the duplicated documentation in the next commit.

[kyrias]

I feel like ChannelNExist isn't a very clear variant name. How about something like InvalidNodeId, NoSuchChannel, or NoMatchingChannel?

[kyrias]

Having the documentation of the return value in the same paragraph as the method's purpose feels somewhat hard to read to me. I'm also not sure if there's much value in documenting the success case, since it's ultimately just "if no errors occurred." What do you think about something like the following?

Suggested change

	/// Call `blocking_recv` of the receiver of the given `NodeId`. Returns `Ok(Content)`
	/// if message received; returns `Err(RecvErr)` if the given `NodeId` is invalid, no message is available to recv,
	/// or err occurs.
	/// Perform a blocking receive on the incoming channel from `NodeId`.
	///
	/// # Errors
	///
	/// This method can return the following errors:
	///
	/// - `RecvErr::ChannelNExist` if the given `NodeId` was invalid.
	/// - `RecvErr::Closed` if all senders were dropped.
	/// - `RecvErr::Lagged(x)` if some messages were dropped before the receiver could receive
	/// them. Contains the number of messages lost.

Though it also doesn't feel great to essentially duplicate the documentation for the RecvErr type on every method that returns it since that's a recipe for partially updated docs, but it would be nice to make it clearer that InChannel::recv will never return RecvErr::ChannelNExist.

I wonder if it would be better to have one RecvErr for InChannels and a separate one for InChannel. Right now if someone were to call InChannels::get and then use InChannel directly they would need to handle the RecvErr::ChannelNExist case even though it should never be able to happen.

[191220029]

I prefer your suggestion to modify the document. I will update the documentation here in my next commit.

For the err type, we want users to receive messages from other nodes directly through InChannels, without caring what InChannel is. That's why I defined the methods implemented for InChannel as private items. Maybe we can define InChannel as a private item too?

So I think we don't have to create a separate Err type for InChannel? because on the user side they should not know the existence of InChannel.

[191220029]

I checked the doc of tokio mpsc & broadcast and found that we can merge the error types SendErr::MpscError and SendErr::BcstError into a single ChannelClosed, because the send operation of mpsc or broadcast will only fail if there is no active receiver (i.e. closed channel).
More detailed info can be found in the src code of tokio: mpsc::SendError and broadcast::SendError

Suggested change

	BcstError(broadcast::error::SendError<Content>),
	ClosedChannel(Content),

[fengyang-nju]

It looks good to me.