Re: [Loco-dev] File Sharing development

[Janico Greifenberg]

On Fri, May 24, 2002 at 07:00:00PM +0200, tok wrote:
> hi guys,
> 
> sorry about the log entry, no harm intended. to clearify: i fixed a
> brain-dead mem-leak i created myself (a few hours earlier).
> about the user list function: i just saw the comment work-in-progress,
> had a need for something (which i'd have called like that) and did what
> seemed logical.
> arne> won't break anything else (g)... by the way, no need for
> compliments (G)

no problem.
 
> the productive part:
> 
> about filesharing: as i understand it, the loco tree allows searching by
> gpg-key-ids (name, comment, email). thus a signed file would have some
> unique id. [may one node have unlimited files? - how many keys may it
> have at once. may i have foreign keys (files signed by anybody else)]
> when files are split, each segment should imho have its own id, all of
> them somehow linked to the total_file id.
> any thoughts?

The details about searching for files have yet to be worked out. But not any
file will have its own key in the tree, but there will be a system of peers
maintaining a search database of some kind. For the searching for persons in the
tree we actually planned to search for comments (which we use as nicks) only,
but now that I think about it, I'm in doubt. The advantage of nickname only is
that one name is easier to memorize than the gpg-key-id tripple. On the other
side when the loco gets more useres, finding a unique nick gets a pain in the
ass and we get names like divo_1024B. But we have some time until we need to
decide that. 


> about proxying:
> i have made a few changes for proxy support (local only). what i think:
> 
> - i seem to have to differ between directly reachable and firewalled
> nodes, added a boolen firewalled to LocoPeer

That's true. And we need another LocoType for forwarded messages which we should
write in a way that we can also use it for mixmaster anonymization.

> - a loco node acting as proxy for another node will probably need
> another task and two ports (one listener connected to the fwed client
> and another one as outbound listener for that client)
> imho the more nodes one is proxying for, the less likely it should be
> that it will accept another proxy request... but howto implement?

I don't think the proxy needs another port and thread for connections to his
clients, as the thread waiting for connections on tcp/ip level only reads
the header and than returns into its listening state. Maybe we can start a new
thread when forwarding a long message so tree messages are not delayed but we
don't need that yet. For the limit of proxy clients maybe something like:
client -> proxy1: proxy request
proxy1 -> client: n_clients1
client -> proxy2: proxy request
proxy2 -> client: n_clients2
if(n_clients1 < n_clients2)
   client -> proxy1: do proxy

> - should there be different request types (from fwed clients to an open
> node)? e.g.: 
> proxy - connect_loco_network (just messaging)
>       - connect_and_proxy (open listener for others to reach me)
>       - get_file
>       - send_msg
>       - get_http
> we would need some protocol for this ;-(

You don't need the proxy for outbound connections. Only the connections you
receive are relayed.
 
> concluding: i need more docs. got anything(!) written down about the way
> the tree should work?

So far we only have what's on out website, but I rethought my "document it when
it exists"- policy and I will write something.

So long 
   Divo

-- 
Warning! Taking anyone (especially yourself) too serious will be harmful

pgpktqBPfaIPc.pgp
Description: PGP signature