It’s really good, actually. The different impl’s though (go/rust/python) do differ in terminology used and also API. So there is some wrestling to use it correctly. We have tended to do it all ourselves and the key here is to use s much as libp2p has to offer and for us not to customise / fork/ rewrite parts. So we are really pushing it’s limits before we add in some Safe magic. So far it’s a wrestle to do that, but we are getting there.
Still, no NAT with QUIC yet, but TCP looks like it’s close enough. So we will end up with a load of TCP testnets which is a shame as QUIC is so much better/faster/lighter etc. but that is all OK.
Patience grasshopper. These can only be built on solid foundations. There is still a (little) bit of concrete to be poured before we can confidently spend time on a browser and APIs. Remember a lot of that work is done already, we will not be starting from scratch. Just need to be certain exactly what we are building on top of.
So we will have relatively resource-heavy nodes for the next wee while then?
I say relatively, last night I had 25 nodes running in 12-14Gb RAM, uploaded 2000-off 10k files and downloaded them all without apprent error. No substantial “ratcheting” of the memory and CPU use seemed a bit lower than the past few days.
Anyhow - building the latest and I’ll try again.
Not so good today: I was only able to download 641/2000 5k test files with the latest from GH. Much more testing needed to confirm/deny this performance.
Still failing - but with a degree of consistency - I am only ever able to download 6-700 files out of 2000 uploaded. This figure is constant(ish) over 5 runs no matter if I store files of 5kb random data or filesizes in the range 1-100k.
Right now it looks like libp2p is optimised for smaller records and less churn (and so less republishing). They operate in the span of days we operate in the span of seconds to minutes (or would like to). Really we want to be doing data republishin on any churn.
So relying on their impl for large chunks etc is a balancing act.
Right now we’ve seen the limits of that approach and how it’s not necessarily optimal.
As @dirvine says, we’re really pushing libp2p and seeing what we can get away with there. I think we’ll be on a hybrid approach for a bit while we see what would make sense for libp2p.
So right now we’re looking at what would be optimal and how that might work into libp2p to see if there’s some PRs we could upstream there
Which adds some nightly job runs (this is where we’d want larger tests like you’re trying). The resources are limited (one github machine), but we could look to run a 2k file upload/download eg every day on CI to caatch regressions in perf here…
Let me know if that’s something you might be interested in and if you need any help / pointers!
That is still happening. Right now it’s getting DBCs working well and securely. Then we will add the payments to upload. We need that to prove data is valid (i.e. it has been paid for) to allow data republish should any ever be lost etc.