Trying to model hypercore-protocol in Rust, and wow yeah okay this is pushing the boundaries a bit of what established Rust stream patterns can provide. Currently using the codec pattern + modelling it after crossbeam channels, but it's not *quite* righthttps://github.com/mafintosh/hypercore-protocol …
-
Show this thread
-
Okay done for today. Research so far is in this doc: https://paper.dropbox.com/doc/2019-07-17-Hypercore-Network-Protocol--AhNEGkO5FvBBgr7Wt3cPjs3VAg-4B3OhCO3vPtphqT82Lidg … Tl;Dr: hypercore-protocol multiplexes multiple feeds over a single connection, which means we're having two layers of things that need to stream in and out. It's really good, but ooph this isn't easy.
1 reply 0 retweets 4 likesShow this thread -
Where "single connection" == AsyncRead + AsyncWrite. Using Hyperswarm this could be backed by a plethora of connection methods, but the interface should remain consistent.
2 replies 0 retweets 0 likesShow this thread -
It doesn't even quite compare to some other multiplexed protocols such as h2, because there isn't a clear distinction between client & server — each instance is both. I'm now wondering if we need a 3-layer hierarchy for this
1 reply 0 retweets 1 likeShow this thread -
Top-level: create a protocol instance that streams bytes in and out. Mid-level: each proto instance can create a channel. Each channel can be split into (n) senders + 1 receiver. Low-level: each receiver emits a stream of events.
1 reply 0 retweets 0 likesShow this thread -
I think actually what we need is a closure in the Protocol constructor to construct new channels from! let proto = Protocol::new(|p| http://p.channel (key)); let (r, w) = proto.split(); // now pipe these parts to the network
2 replies 0 retweets 1 likeShow this thread
(okay, I think I'm done thinking out loud for now)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.