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 -
Replying to @yoshuawuyts
What would r,w mean ? I always let (rx,tx) = mpsc::channel();, only to figure out later I (again) got it the other way around. ^^
1 reply 0 retweets 0 likes
I updated the doc with a new design. I usually prefer writing let (reader, writer) = channel() as there's less chance of confusion.
@stjepang goes into quite a few details of the naming problems std's channels have here:https://stjepang.github.io/2019/03/02/new-channels.html …
-
-
Replying to @yoshuawuyts @stjepang
Wow that's a thorough and clear article. I had a great time reading it, and it makes total sense wrt the public api, thank you for sharing it !
0 replies 0 retweets 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.