World: r3wp
[All] except covered in other channels
older newer | first last |
Pekr 7-Jan-2005 [381x2] | 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 | |
Gabriele 7-Jan-2005 [383] | exactly. it is very good for implementing DHTs (Distributed Hash Tables) |
Pekr 7-Jan-2005 [384] | (schemes), Rugby, Rebservices, Uniserve .... |
Gabriele 7-Jan-2005 [385] | messaging.r is what I need until RS are out :) |
Pekr 7-Jan-2005 [386] | 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? |
Gabriele 7-Jan-2005 [387] | AFAIK it will. |
Pekr 7-Jan-2005 [388] | hmm, and if RS will not provide any such advanced look-up mechanism? (as I expect it to not) |
Gabriele 7-Jan-2005 [389x3] | 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 | |
Pekr 7-Jan-2005 [392] | 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 ... |
Gabriele 7-Jan-2005 [393] | Indeed, that's why I think we need a DHT instead of a catalog service for RS |
Pekr 7-Jan-2005 [394] | ah, ok, so Chord is independent of messaging.r, messaging.r being just temporal solution till RS appear ... |
Gabriele 7-Jan-2005 [395x2] | a catalog service is a single point of failure. |
exactly... | |
Pekr 7-Jan-2005 [397] | 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 ... |
Gabriele 7-Jan-2005 [398x2] | 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 | |
Pekr 7-Jan-2005 [400] | 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? |
Gabriele 7-Jan-2005 [401x3] | 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. | |
Pekr 7-Jan-2005 [404] | 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? |
Gabriele 7-Jan-2005 [405x2] | 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. | |
Pekr 7-Jan-2005 [407] | 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 :-) |
Gabriele 7-Jan-2005 [408x2] | My implementation will be BSD |
with 1000 nodes, Chord will need, on average, about 10 steps to find the target node. | |
Pekr 7-Jan-2005 [410] | 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.? |
Gabriele 7-Jan-2005 [411x3] | 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 | |
Pekr 7-Jan-2005 [414x3] | 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 ... | |
Gabriele 7-Jan-2005 [417x2] | 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. | |
Pekr 7-Jan-2005 [419] | hmm, but then each client would have to contain AltME server mode too, no? |
Gabriele 7-Jan-2005 [420x2] | 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. | |
Pekr 7-Jan-2005 [422x2] | but that is a lit bittle different principle. Current AltME is still example of client-server type app, isn't it? |
hmm, I start to like that P2P based messaging :-) | |
Gabriele 7-Jan-2005 [424] | exactly. |
Sunanda 7-Jan-2005 [425] | Gabriele: How could I uarantee to connect to a node that is online right now? |
Pekr 7-Jan-2005 [426] | hmm, what about products like IOS, where you e.g. want too to have some P2P messaging, but you also want to have in control, what server, client, talks to what side, etc. |
Gabriele 7-Jan-2005 [427] | yes - imagine people with just dial-up connectivity being able to start worlds and so on. |
Sunanda 7-Jan-2005 [428] | uarantee = guarantee |
Gabriele 7-Jan-2005 [429] | control is achieved via authorization. I have in my mind a distributed authorization system - no wonders, just applying known things the right way :) |
Pekr 7-Jan-2005 [430] | I mean - I want to have closed (as IOS) network of users ... some other user starts chord and tries to send message ... I hope chord is just about look-up, so I still be able to implement authentication and other dialect based protocols/services in upper layers? |
older newer | first last |