Thomas Eizinger comments

Results 1888 comments of


                                            Thomas Eizinger

Set a better default for `idle_connection_timeout`

An active gossipsub stream will keep the connection alive even if the nodes aren't subscribed to the same topics. There isn't really much we can do about that. The best...

feat(kad): use `Bytes` for `Record::value`

> @thomaseizinger Are there any blockers to landing this at the moment? Are we looking at the protobuf `Cow` work as a prereq? (I'm a bit stalled there, not sure...

feat(kad): use `Bytes` for `Record::value`

> I'll try and form a minimal change from our codebase (with the libp2p branch being the only diff) and get some numbers / repro steps if that's helpful 👍...

Update libp2p_kad::store::RecordStore trait to be amenable to a persistent implementation

Related: https://github.com/libp2p/rust-libp2p/issues/3035.

Update libp2p_kad::store::RecordStore trait to be amenable to a persistent implementation

There is a long discussion in https://github.com/libp2p/rust-libp2p/pull/3076 that is highly relevant for this. I am still of the same opinion that I think we should design `RecordStore` to: - Implement...

Update libp2p_kad::store::RecordStore trait to be amenable to a persistent implementation

Looking at the interface, what are these functions actually used for? We don't need them within `libp2p-kad`, do we? Thus we could also just remove them and move the responsibility...

Update libp2p_kad::store::RecordStore trait to be amenable to a persistent implementation

Could we implement republishing by just returning a list of _keys_ and then fetch each key individually? That would reduce the memory consumption to only fit all keys into memory....

Update libp2p_kad::store::RecordStore trait to be amenable to a persistent implementation

> For our use case we are using provider records exclusively and so the key is the significant portion of the data. We expect 10M+ keys for a single peer....

Update libp2p_kad::store::RecordStore trait to be amenable to a persistent implementation

> What if we split these concerns of re-publishing and the store into two different traits? > > * RecordStore - only does get/put of records > > * PublishJob...

Update libp2p_kad::store::RecordStore trait to be amenable to a persistent implementation

> Its the idea the rust-libp2p would contain two kad behaviors? The low level one and the wrapper that does what the current implementation does using an in memory store?...