[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: available resource declaration language(s)
David Santo Orcero wrote:
> > For instance, it is easy to imagine a virtual ring architecture
>
> This idea will work fine on little networks, but I strondly doubt that
> something like these scale well. If you have only one token, you have some
> technical problems.
The technical problems are not insurmountable. Who said the virtual ring
must have only one token, or there must be only one virtual ring?
> 1) What will happed if a node hangs if he is with the packet? (it will
> hang the whole parallel process in cluster, you will need a complex
> negociation rule to create a new token, like in token ring networks)
like, if you need a resource and you have not received a token recently
you send out a token. The implementation of a robust token ring architecture
is not only tractable, but well documented.
> 2) What will happed if a malicious/erroneous node send a new second token
> to the network? (on a P2P protocol, a malicious/erroneus node have
> shorter posibilities to damage the network; anyway, Mosix solution is also
> far away of being safe)
if the route of the token can alter, or fall back on p2p methods, there can
be error recovery
> 3) If the network is really BIG -500, 600 nodes- the delay to get the
> token will be a problem. Somebody can say -buy a faster network-; but it
> is better not to force to the user spend more bucks because we use a worse
> solution.
so the network divides into teams of ten, based on subnet (I hope all 500
nodes are not on the same LAN segment) and a token is passed w/in each team,
and the team spontaneously elects a Decurion to present the team to the other
49 Decurions, via p2p or virtual token ring architecture at that level.
For on instance of full presentation among 10 nodes, with p2p there are 90
communications required (not counting the omphalotic case) and with VTR there
are ten communications required.
> The three problems can be solved in a broadcast net, as proposed? No! If
> you have enougth nodes, you will flood the network; that is why I am
> really sure that using broadcast features it will not work.
Broadcast scales better than p2p -- it is p2p that floods a large network.
Rings and broadcasts both scale better than peer-to-peer, because there
is less redundant information streaming around.
> Personally I think that, independent of using Mosix arch or other
> completly thing, the architecture and the protocolls must be peer-2-peer,
> and all negociations must be distributed, using a random query as method
> of beginning a new P2P negociation; exactly as Mosix does. This will give
> to us an escalable and failure-proof method to negociate the share of the
> resources and to exchange information with other nodes.
How about a peer-to-peer abstraction over an arbitrary discovery mechanism,
in which data has a variable TTL, similar to, or even built on top of, DNS?
type RR into http://www.rfc-editor.org/cgi-bin/rfcsearch.pl to see what there
is available in DNS Resource Records. That kind of thing might be better as
an IETF standard than a linux extension... It's monday and I can move mountains :)
Linux-cluster: generic cluster infrastructure for Linux
Archive: http://mail.nl.linux.org/linux-cluster/