[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A proposal for a General Clustering Framework




----- Original Message -----
From: "David Brower" <David.Brower@oracle.com>
To: "Alan Robertson" <alanr@unix.sh>
Cc: "Michael E Brown" <michael_e_brown@dell.com>; "linux-cluster"
<linux-cluster@nl.linux.org>
Sent: Tuesday, June 05, 2001 12:58 PM
Subject: Re: A proposal for a General Clustering Framework

...

> Someone else complained about the byte size of the encoding.  I think
> we need to be over this kind of issue.  I don't believe the bandwidth
> utilization is particularly relevant anymore

While bandwidth may be less relevant (though it's seldom *completely*
irrelevant), switch-level buffering considerations sometimes make it
desirable to be able to fit a message into a single Ethernet packet.

...

> impression is that many cluster people (including those I
> work with) aren't adequately comfortable or familiar with
> RPC systems, and tend to think in terms of sending raw structures
> as messages over a channel to a homogeneous system running the
> same code at the same version on the other end.   (And usually
> over a private network so security issues can be punted).

Sending raw structures works only in homogeneous-endian environments anyway
(though file systems do need the ability to send raw file data as
byte-strings, since they haven't a clue what the internal structure of it
may be and must leave interpretation up to the application).  My own
reservations (which my impression is may be shared by others here) center on
overheads - e.g., the arbitrary requirement for a response (though a flag
requesting datagram-like behavior covers that) and the lack of fine control
over marshalling activity (including the potential for [distributed]
resource-allocation deadlocks).

- bill



Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/