--On Tuesday, May 11, 2010 02:20:13 PM -0400 Derrick Brashear
<[email protected]> wrote:
On Tue, May 11, 2010 at 1:56 PM, Jeffrey Hutzelman <[email protected]> wrote:
--On Tuesday, May 11, 2010 09:45:14 AM -0400 Derrick Brashear
<[email protected]> wrote:
As part of the work done by Vishal Powar, my Google Summer of Code
student two years ago, we have the start of readwrite replication in
RT (http://rt.central.org/rt/Ticket/Display.html?id=114116)
It necessarily adds a server to server RPC protocol, which is below.
However, it is effectively the needed subset of RPCs to create data,
and the client ViceId of the caller.
I intend to offer a standards proposal for this, instead using the
signatures of the proposed "RPC refresh" RPCs, again with the client
ViceIds added, with the idea that an additional Rx "service" is run on
each fileserver to accept these.
Would this be a reasonable proposal?
Sounds reasonable.
For a new service, let's start RPC numbers at 1; there's no reason to
start with large values in a service where we don't have to worry about
IBM allocating numbers out-of-process.
I meant to change those to XXX; That was from his reference patch,
which used the existing Rx service and just added RPCs, while he was
testing.
If you're creating a new service, you should go ahead and pick RPC numbers.
New registries should come with initial contents, not an initial backlog of
requests. :-)
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
