out of curiosity, what are your thoughts on DDD? dunno if I should bother learning it... normally the people into it are knee-deep into OOP

IMO DDD is a great resource to draw inspiration from, works equally well for functional programming

as with all methodologies the key is to use your brain while applying it and not taking everything literally/to the extreme 😛

the give an answer to robert’s question: if you have some programmer you look up to, I recommend reading their code and see how they do things, and make your own notes about their design choices

perhaps something like these: http://aosabook.org/en/index.html

Not a programming book, but it can applied to programming (specially UI design) very easily: The Design of Everyday things

There's positive talk recently about "causal modeling" for use in the scientific method. Perhaps we'll have Causal Driven Design one day https://en.wikipedia.org/wiki/Causal_model

There are so many different kinds of design, and scales, and scopes. e.g. are you more interested in the design of a single codebase, or of multi-tier apps, or of entire distributed system landscapes?

I prefer D&DD

I play dungeons and dragons

and eventually develop something

sometimes DD&DD if i want to add a design phase

@U45T93RA6 I’ve been enjoying this book https://pragprog.com/book/swdddf/domain-modeling-made-functional on the subject

@U69US348Z I suppose I meant: how do you turn requirements into a solution that doesn't explode? That's a really general question, but I kinda just wanted to get into someone else's head when they start problem solving. What things are they looking for? What questions are they asking themselves? etc.

here you go: https://stackoverflow.com/questions/310607/peer-to-peer-methods-of-finding-peers

Usually a DHT

And use geoip to get locality, if you want geographically "nearest" neighbors.

I’m reading about DHT right now, but how can I ask the peer if I don’t know where it is

I mean, assume I have cluster of nodes (peers) having finger-tables (if we talk about Chord), but I need to send the request to at least one node in order to trigger the search

client --- X ---- interconnected peers

For the initial entry to the network, "seed servers" usually push out a seed list of peers, to get you started on the network.

:thumbsup: Thanks

That's probably one of the more dangerous points in the untrusted p2p situation. Malicious seed servers could be very dangerous. Sorta of a centralized/achilles heel of distributed systems.

Another option is f2f, where your friends are your seed servers, and you enter the network locally via some friend.

f2f?

those are the systems I see in my lecture slides.

friend2friend... provides more anonymity/privacy, if that's a goal

thank you! much appreciated. Doing distributed systems course right now at the uni and was kinda confused on this topic

hmm... strange. Both gnutella and freenet use DHTs, iirc. I wouldn't be suprised if most of the others there did too.

what are your thoughts on DHTs with/without the router component? I was just thinking about the router component/server (with replicas, e.g. 3) having the whole routing table for all live nodes (update the table while sending heartbeats every x seconds). This way the search would be O(1) with the cost of only 3 (or more, depending on replica policy) nodes, instead of being O(logN)

Absolutely... If you're not building some global thing, but a distributed thing of a controlled size, of under, say, 10,000 nodes, why not just keep the whole netdb on every router? People way over-engineer "distributed systems" with ideas around global fault tolerance, when they're only dealing with a few dozen servers. Crazy.

But like everything, it depends on what your goals are.

Thanks! Makes sense

No prob. Good luck! I hacked on some p2p stuff back in the day, so let me know if you have any questions and do tell if you make anything cool!

Want to build a DHT (described in Chord paper) for fun and practice in Clojure. For this I would assume I need a RPC lib. Any lib you know is good? Slacker?

https://github.com/sunng87/slacker

For any bits that you'd expect to use RPC for, I'd recommend trying to replace those with a data-first approach.

ouuuu thanks! learning something new 🙂

Yeah, a lot of older write-ups on chord-like architectures might have RPC idioms going on. But if you think about it, all RPC is all data over the wire anyway, so whatever RPC is doing for you, you can do with just data. And in clojure, ideally, you're working with data anyway.

RPC is kinda fancy and trendy nowadays 🙂 one could do both and then compare performance/readability(maintainability)

So it's best to avoid RPC unless you have to work with some legacy idioms for whatever reason... Or if you explicitly want to provide the illusion of locality

Yeah, in some circles. Def couldn't hurt to try both!

definitely need to read more on RPC and check the pro/contra argument. Go with gRPC seem to be kinda trendy atm (doesn’t imply it’s good though)

Also bear in mind, if any of your RPC method calls are synchronous then you may have some difficulty porting to a JS based host, like cljs, since blocking in JS isn't quite a thing.

can not one wrap it around a go-routine with core-async for instance?

Yeah, but then all your users are required to play that game too

under all your users you mean peers, right?

Might be a fair trade off. Depends on who your users are and the problem the system solves. No, I mean users of a clojure chord or dht lib

If it's only you, whatever works for you and your collaborators

nice. thanks man!

Np! 👍

BTW, is there any channel for clojure code review or smth?

Yup, #code-reviews and #architecture but you should probably cross post here or another related, more popular channel, to get people's attention and come over and check it out. Otherwise folks might not see it.

great :thumbsup:

BTW regarding the API, I guess one would like to have same API as a standard hash-map in clojure (with assoc, get) meaning it would be synchronous this way, dunno

Sure, for the high-level api, and yeah that'd imply synchronous. Certain clojure programmers will frown on that rpc-like/map-like thing you've created 😉 But I fancy familiar interfaces when their differences are made obvious. For a low-level API, you may want to stick to the asynchronous reality, and go as event driven / reactive as possible.

cool. sounds like an interesting project to implement! need to make it real 😅

https://clojurians.slack.com/archives/C03RZGPG3/p1545586775033800

any thoughts on this? you seem like you know some stuff 😎