Maybe IChannel in DialAsync and ListenAsync for ISessionProtocol should be System.Threading.Channel

[Xyncgas]

.NET has System.Threading.Channels and it's really performant it can be a solid ground for people implementing their own multiplexer once the connection has opened and peers engaged in session communications
For example, System.Threading.Channels.ChannelWriter.WriteAsync exist to let multiple threads writing to the channel

[Xyncgas]

Can create an api wrapping around the existing IChannel and use System.Threading.Channels for multiple threads writing their bytes to IChannel and it can be recognized through method consumer's implementations
Enabling : Dial Peers -> Session Engaged -> {Kademlia Exchange Of Peers + request for remote + sending bytes to complete different requests received} simultaneously as long the session is not disconnected

[flcl42]

Feel free to experiment. The aim of implementing a custom IChannel was the following:

• make it convenient for protocol developers, so they can read fixed amount of data or anything that just received
• don't copy data when it's passed through the protocols
• eliminate allocations oh heap
• support multi-threading
• still be performant

If you want to try to replace em with some existing stuff, first of all I'd suggest to provide benchmarks that it supports the idea it's can be faster. The typical scenario:

• data received from network
• decrypted (noise)
• sent to multiple protocols via a multiplexer (yamux)
• traverse back after being assembled and encrypted

[Xyncgas]

I was ignorant and I am sorry

• After reading the implementation of Channel.cs I can see it's simply a reasonable way for reading and writing bytes
• I had System.Threading.Channel and System.IO.Pipeline mixed up and I was actually thinking maybe I should replace Nethermind.Libp2p.Core.Channel with System.IO.Pipeline and enabling multi-threaded reading and writing
• Yet I realized it's just a facility for people to get and write bytes, and it's the transport protocols actually reading bytes, the protocols can use System.IO.Pipeline if it's needed there
• Actually, I am not grasping the whole picture still, it seems IChannel is given to the transport protocols to write to and the same IChannel is given (after reversing) in say ISessionProtocol.DialAsync for people reading bytes, and I assume the operations are supporting multi-threaded reading and writing, because all the Semaphores locking in Nethermind.Libp2p.Core.Channel
• Now I am believing I can change Nethermind.Libp2p.Core.Channel to use System.IO.Pipeline but I do not know if I should, the current solution looks elegant and I like how that channel gets reversed and provided to the ISessionProtocol's DialAsync / ListenAsync, and System.Threading.Channel can apparently be something implementing over IChannel for applications to run Serialization and converting between bytes and structured datas

I liked the company name 'Demerzel'

[Xyncgas]

I'm going to create a pull request for adding documentations in https://github.com/NethermindEth/dotnet-libp2p/blob/a3d1c5802eac6ccc1c20b7cfc1412fd9c72d7eaf/docs/README.md saying the channel supports multi-threaded reading + writing
And the behavior for operations which doesn't return ReadResult in IChannel is actually throwing exceptions if failed according to

dotnet-libp2p/src/libp2p/Libp2p.Core/VarInt.cs

Line 105 in a3d1c58

byte @byte = (await buf.ReadAsync(1).OrThrow()).FirstSpan[0];

and

dotnet-libp2p/src/libp2p/Libp2p.Core/UnwarpResultExtensions.cs

Line 25 in a3d1c58

public static async ValueTask<ReadOnlySequence<byte>> OrThrow(this ValueTask<ReadResult> self)

[Xyncgas]

I can not believe people wrote all these code it makes so much sense it's beautiful

[flcl42]

Thanks!