diff options
| author | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
|---|---|---|
| committer | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
| commit | 0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch) | |
| tree | 2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2000-December/000082.html | |
| download | nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip | |
Initial commit
Diffstat (limited to 'pipermail/nel/2000-December/000082.html')
| -rw-r--r-- | pipermail/nel/2000-December/000082.html | 75 |
1 files changed, 75 insertions, 0 deletions
diff --git a/pipermail/nel/2000-December/000082.html b/pipermail/nel/2000-December/000082.html new file mode 100644 index 00000000..aa9812a0 --- /dev/null +++ b/pipermail/nel/2000-December/000082.html @@ -0,0 +1,75 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Nel] Suggestion for the NeL network library / architecture</TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:x5101920%40fedro.ugr.es"> + <LINK REL="Previous" HREF="000081.html"> + <LINK REL="Next" HREF="000083.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Nel] Suggestion for the NeL network library / architecture</H1> + <B>MIGUEL ANGEL BLANCH LARDIN</B> + <A HREF="mailto:x5101920%40fedro.ugr.es" + TITLE="[Nel] Suggestion for the NeL network library / architecture">x5101920@fedro.ugr.es</A><BR> + <I>Tue, 12 Dec 2000 11:48:18 +0100 (MET)</I> + <P><UL> + <LI> Previous message: <A HREF="000081.html">[Nel] Suggestion for the NeL network library / architecture</A></li> + <LI> Next message: <A HREF="000083.html">[Nel] Suggestion for the NeL network library / architecture</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#82">[ date ]</a> + <a href="thread.html#82">[ thread ]</a> + <a href="subject.html#82">[ subject ]</a> + <a href="author.html#82">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>><i> That's where PGM/multicast intervenes. In that model, the agent, +</I>when he +><i> changes some of his variables, notifies the replica that "XYZ are +</I>now...". +><i> I spoke about how the world services organise where an agent +</I>resides. In +><i> some models, you have about one, maybe two replicas, which you can +</I>notify +><i> using a standard TCP stream. Or RDP. But, if you want a +</I>load-balancing +><i> system, you quickly end up with a replica of an object in most world +</I>><i> service processes. It becomes then more efficient to multicast the +</I>updates +><i> as above to all processes, and update them all in one sweep. +</I> +Ok, I always have though of load balancing as load-work division +between servers. + +I think that the above kind of working can have several inconsistences +, just take a look to some distributed Mutual exclusion algos. + +Just imagine that both copies of a object multicast different +positions, you have to choose what is the best one, and whatever your +choose is, it will be wrong, and servers can't be wrong. + +Replycating work can be a real pain. +And for what you have said multicast isn't a solution for end-users. + +I think that IPv6 will fix these things, by having a multicast in the +standart, isn't it? + +</pre> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI> Previous message: <A HREF="000081.html">[Nel] Suggestion for the NeL network library / architecture</A></li> + <LI> Next message: <A HREF="000083.html">[Nel] Suggestion for the NeL network library / architecture</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#82">[ date ]</a> + <a href="thread.html#82">[ thread ]</a> + <a href="subject.html#82">[ subject ]</a> + <a href="author.html#82">[ author ]</a> + </LI> + </UL> +</body></html> |