World: r3wp

chord: will be there tomorrow or so.

i have a prototype that can be easily translated to real code using 
messaging.r and the in-interval? function you see there.

so i just need to change the prototype code into real working code... 
and then test it a bit.

Chord needs messaging.r, not viceversa.

What will we be able to do using Chord? I heard Chord is not about 
P2P (sharing), but some look-up mechanism. Any examples how all that 
stuff could be used within some kind of interesting project/product?

any P2P network needs routing as its basis, doesn't it? Chord provides 
that by providing distributed lookup.

that is, if Gabriele wants to send a message to Petr, he has to know 
where Petr is. In some P2P networks this is handled by sending a 
message to someone esle and route it up to Petr.

with Chord, you directly look up where Petr is and then send a message 
to him directly.

I guess this is the easiest explanation I can give of it :-)

Hmm, interesting. Could be used for look-up of Rebservices later 
:-)

I just wanted to have better idea of how all that stuff compares 
... protocols

exactly. it is very good for implementing DHTs (Distributed Hash 
Tables)

(schemes), Rugby, Rebservices, Uniserve ....

messaging.r is what I need until RS are out :)

I can see Uniserve a multiplexing engine, multiprotocol ... while 
Rebservices could be sent via e.g. IRC procol, whatever - it will 
probably be independent (to some extent) of transport mechanism?

AFAIK it will.

hmm, and if RS will not provide any such advanced look-up mechanism? 
(as I expect it to not)

mine is not, because that is too much effort. (but it is partially)

Chord can be implemented over RS instead of over messaging.r

Chord could be just implemented over UDP too etc., or over Rugby 
and so on

From what I read so far, it seems to me RS are similar to WS, - exposed 
functionality, and you don't do any look-up, you have to know where 
is catalog providing you with description of service and its location 
...

Indeed, that's why I think we need a DHT instead of a catalog service 
for RS

ah, ok, so Chord is independent of messaging.r, messaging.r being 
just temporal solution till RS appear ...

a catalog service is a single point of failure.

exactly...

maybe we could use both of worlds? But then - I can see it with most 
P2P networks - once someone decides to shut-down central site, whole 
system collapses ...

Chord in itself is an algorithm, we call it a protocol because it 
involves more nodes talking to each other

real P2P (i.e. fully distributed) has *NO* central site

how large is Chord in kbs? And - is that good protocol to be added 
into rebol for e.g.? How does it compare to gnutella2 or others?

of course you need bootstrap nodes, bu that's it.

my prototype of Chord (very basic, but should be a good start) is 
105 lines of rebol including header.

gnutella and similar are *VERY* primitive and slow compared to Chord. 
Chord can handle billions of nodes with good performance. I don't 
thing gnutella can.

ok, now another question. Let's say that currently you know, that 
there is http://www.rebol.com/RSs/calc-time.r, so you know direct 
path ... how much penalty will there be with Chord, if you do something 
like send-message [calk-time-:-at-rebol-com], simply if it will start 
to look up?

It is more advanced than Skype, for example. Skype is stile a hierarchycal 
network.

the time required for a look up depends on the number of nodes.

hmm, then we could agree on Chord as de-facto-standard for rebol? 
Does its licence allows its icnlusion by RT for e.g.? I mean - it 
is better to agree upon some decent standard which everyhone will 
use instead of having none, when noone will use nothing :-)

My implementation will be BSD

with 1000 nodes, Chord will need, on average, about 10 steps to find 
the target node.

well, and if there is not enough of nodes? While I would be able 
to reach RS directly using web-address (catalog), may RS fail? Or 
will your node contain few basic service sites for e.g.?

with 10000 nodes, it's about 13 steps.

you will need at least one bootstrap node that is always available.

usually what you do is keeping some 10 bootstrap nodes in different 
parts of the world so that you can be sure that at least one is always 
available

hmm ... will I be able to have kind of "cache" to have actually more 
than one possible on-line, so working, node? :-)

:-)

you are faster ...

for example, if AltME was based on a DHT, to make it fail you would 
need to kill all nodes; and to make it lose data, you would need 
to kill almost all nodes.

using state of the art tecniques it is possible to retain 99,8% of 
the data in a DHT when half of the nodes fail.

hmm, but then each client would have to contain AltME server mode 
too, no?

yes, basically there is no server at all. the server is the sum of 
all clients online.

this also means that you don't need a physical server machine to 
run an AltME server.