[Protocols] Common connection object for client and server
KPixel opened this issue · 5 comments
It is great to see Project Bedrock moving forward in #1446 :)
One thing that I am noticing is that ConnectionContext is the connection object on the server while IConnection is the connection object on the client. And they both use IDuplexPipe as the underlying "bytes-passing" object.
This means that we can write libraries that only depend on IDuplexPipe to send and receive stuff, which is nice.
However, we can't do the same for connections:
For example, in a server-to-server scenario (and more generally, peer-to-peer), any device can initiate a connection to another device. And ideally, a device would want to manage all connections (both those that it initiated and those that where initiated to it) together.
So, let's say A connects to B, B connects to C and C connects to A. (So, we get a mesh network.)
How do we write a library that allows A to broadcast messages to B and C?
Another way to think about it is: Once a connection comes out of the "factory", it shouldn't matter how it came to be.
I'm working on it. There's a master plan somewhere here but there are some design challenges to be worked through. Some discussion started here #1450 and I took a crack at it last night but the calling pattern is quite a bit different and there are some challenges with shutting down the connection that I haven't yet cracked yet (some of it is explained in that pull request). But I whole heartedly agree that the client can be represented by the ConnectionContext instead of the IConnection using a factory of some sort.
Good to know. Thanks.
I could put together a sample of such scenario. Maybe a peer-to-peer chat console app like Peer Channel Chat...
That would be very helpful.
@davidfowl As discussed, I just published a rough peer-to-peer sample here: https://github.com/KPixel/Prototypes
Kestrel had a lot of what I wanted, so I just copied and adapted its code.