Initial DHT notes #10
Conversation
|
|
||
| 1. Peers can be sorted into five categories: | ||
| - Unconnected peers - have no line with the peer | ||
| - Unconnected seeds - have no line with the peer, but expectation of direct |
There was a problem hiding this comment.
I think the distinction here is subtly different... you have a "complete" hashname, where you know the ip:port and pubkey so that you can (possibly) connect anytime (happens for seeds, but also after you get a connect but never form a line, or after a line is disconnected).
You then have an "incomplete" hashname, which is either just the hashname itself or it plus the ip:port, along with the hashname(s) that you discovered it via. So you can probably connect to it, but you need to ask someone else.
Since every hashname is a peer, you have one third kind, a hashname provided by the app that you are actively seeking, so you don't have any information yet but are in the process of trying to resolve it?
There was a problem hiding this comment.
Today I have:
- A hashname, which is just a string. I also sometimes have a hashvalue in the DHT, which is the value as a big integer.
- Pointer, with hashname, ip, and port
- Peer, which also has a public key
- Seed, which is a peer with an expectation that you can connect directly and the ability to create from JSON
These actually don't save information about pending open packets or lines, because as much as possible I would like these to be data types which are immutable
Instead, the switch has a table for going from hashname to a sent open, and a table from going from hashname to line.
The incomplete hashname (which for me is a pointer w/ reference to server that I seeked it from) doesn't exist as an explicit object today, because you only have a hashname in this state while trying to convert it to a full peer with a line.
There was a problem hiding this comment.
I don't think you can have a Pointer w/o also having the "via" (reference)? Also, you may have multiple Pointers for a hashname (different ip/ports for the same hashname)...
This feels like it's getting close though, It'd be great to get to a common set of terminology for these states across all the implementations, I'm struggling w/ the data models in the various switches I'm working on along these lines, so I appreciate the thought here :)
No description provided.