<!DOCTYPE SGMLwrup>
<GDOC SEC="Provisional">
<FRONTM>
<TITLEP>
<TITLE stitle="RPC Project Status and Requirements"> DD/OC  RPC project status
<AUTHOR> Tim Berners&hyphen.Lee
<ADDRESS>
<ALINE> DD/OC
</ADDRESS>
<DATE> Last update December 1989
This note gives a very brief summary of the state of the RPC system
from DD/OC,
and an list of the extensions and support requested by users,
and a summary of the effort required.

Tim Berners&hyphen.Lee


</TITLEP>
</FRONTM>
<BODY>
<h1> Current Status
The RPC system is basically stable, in that the established
versions have been in use for a year or two, and users have been largely
self-supporting. The user documentation is,
while imperfect, relatively complete,
and both it and the software are available by self&hyphen.service.
There is a VAX/NOTES conference which gives up&hyphen.to&hyphen.date information
about updates, changes, and known bugs. The current release is version 2.4,
with version 2.5 being tested.

Two basic versions of the software exist, one in C and the other in Pascal.
The one in Pascal is the most used, but the C version is expected to become
more important with time. The C version is now more maintainable
than the Pascal version, more portable, and contains more features.
<H1> Internals documentation

This now contains a lot of information, much of it specifically requested.
It will never be perfect, but still needs continual updating.
The internals guide describes algorithms, data structures,
transmission formats, and code management
practice.

The Internals guide was last completely revised in January 1989.
Revision of the flowcharts is a very time consuming business
(using SGML) and so will not be undertaken in a hurry.
<H1> Porting
<xmp>
..tb 9 17 25 33 41 49 57 65 73
     	RS232	Raw	ISO	DECNET	CHI	mail-	TCP/IP	Apollo
     	(V24)	ether.	TP4		link	 box	UDP/IP	NCS/UDP
_______	_______	_______	_______	______	_______	_______	_______	_______

VAX/VMS	OK	OK	OK	OK	OK	undoc	OK+	OK
_______	_______	_______	_______	______	_______	_______	_______	_______

M68020
MoniCa	OK	OK			OK
_______	_______	_______	_______	______	_______	_______	_______	_______

RMS68K		OK
_______	_______	_______	_______	______	_______	_______	_______	_______

OS9	OK	OK	***		**		OK	**
			untest
_______	_______	_______	_______	______	_______	_______	_______	_______

IBM-PC	OK	OK	OK+				untest
MSDOS
_______	_______	_______	_______	______	_______	_______	_______	_______

Mac.	OK	**
_______	_______	_______	_______	______	_______	_______	_______	_______

M6809	OK		OK
_______	_______	_______	_______	______	_______	_______	_______	_______

Ultrix		**					OK	OK
_______	_______	_______	_______	______	_______	_______	_______	_______

Cray							**	OK
_______	_______	_______	_______	______	_______	_______	_______	_______

IBM							FH	promised
VM/CMS							**	undoc
_______	_______	_______	_______	______	_______	_______	_______	_______
</xmp>
<xmp>
	OK	. . . .	Running and supported
	OK+	. . . .	Running and supported, but a separate run-time library
	untest	. . . . Written but not tested
	undoc	. . . .	Running but not documented or supported
	FH	. . . . Frederic Hemmer to work on this
	***	. . . .	Serious urgent user need now.
	**	. . . .	General need, many specific enquiries.
	*	. . . .	Would be probably be useful. Some enquires.
</xmp>

<H2> Under Mac
<UL>
<LI> Port to Mac completed by Roberto Bagnara.
Tested, one bug/improvement oustanding. [Valet]
<LI> When a policy arises about the connection of Macs to ethernets, then
ethernet working will be needed. [Valet]
</ul>
<h2> IBM-PC
<ul><li>
Many versions exist: Pascal for TP4, Pascal for RS232 and Ethernet,
C for RS232, ethernet and TCP/IP.
The last version is to be the supported version. It has been tested over RS232,
and Ethernet, or tested over TCP/IP.
</UL>
<H2> Under Unix
<UL>
<LI>Add DECnet and handling using sockets (and ethernet?)
</UL>
<H2> Under VAX/VMS
<UL>
<LI>Make runtime system into a shareable library.
<li>Integrate C and Pascal versions.
</UL>
<H2> Under OS9
<UL>
<LI> Add RS232 communications ability. [Opal]
<LI> Port and merge CATS handling software for TP4 operation, retest
integrated RS232, Ethernet, TCP/Ip version. [Opal]
</UL>
<H2> For the CHI
Transport over CATS to be integrated with the general M68k transport service.
(Allow ethernet on CHI, and use with RS232) [CHI project, and HVIOR/Valet].
<H1> Extra Features
<H2> User Binding Routine
The ability to specify a user function on the client side
to provide a user defined binding algorithm.
(Mapping of requests onto specific servers
in a user defined way).
[Wisla MPC]
<H2> Server connection/Disconnection routines
The ability to specify user routines on the server side
to be called which clients connect
and disconnect.
This allows sophisticated multithreaded servers to control their environments
more easily. [FASTBUS on CHI]
<H2> Configuration Manager
This is a requirement which crops up again and again,
but tackling it has always required a greater "activation energy"
than we or the collaborations or accelerator groups have had.
It is the problem of authorisation and mapping which I described
in a paper a little while ago.
This is possible a project for a good student, but requires the ability
to specify the problem, and to design the solution at high level,
as well as the design of the machinery and its painless integration
with existing systems.
A configuration manager performs authorisation
and allocation of resources.
It handles local name database, refers to remote
configuration managers, and handles capabilities.
(Delphi, LEP, Opal, etc etc etc)
(Use RPC_ACE program written by Delphi for database?)

The name server side of this has now (Nov 89) been completed by Roberto Bagnara,
in the WAY name server. This is integrated with RPC and would connect usefully
with authorisation systems.
<h2> Indefinte size transfers.
It would be relatively straightforward to introduce fragmantation into the
RPC system allowing the buffer size (typically 8kB) to be  exceeded.
[Delphi offline, etc]
<h2> Compiler upgrades
These would extend the ease of use of RPC, and reduce the amount
of "hand crafting" of stubs.
<ul>
<li> Check for and complain about use in user description file
of words reserved in target langauge
<li> Support for arbitrary actual bounds to subarrays, including
expressions, for arbitrary variable length arrays.
<li> Support for back&hyphen.call package in same definition file.
</ul>
<H2> Compatibility
In the long term, we would like to converge with other RPC systems.
In the medium term, producing options for compatability with these
systems could give us interworking with more systems, eg IBM.


Three interesting systems are
<UL>
<LIHD> Apollo NCS
This is an ostensibly public&hyphen.domain system, with VMS support officially
to come out some time, and operation over various media.
Fabrizio Cane has brought this up on unix, VMS and (to an extent) on the Cray.
OPAL are interested.
NCS has its own protocol which is more complicated than our raw ethernet
protocol,
and an 80-byte packet header (as opposed to 4 to 14 bytes).
<LIHD> Sun XDR.
Sources, are on the priam VAX.
A fairly longstanding RPC system, probably not optimal, but
useful as it exists in various (especially Unix like) environments.
Does not have it's own protocol when running over TCP/IP,
does over UDP/IP.
Does use cannonical form.
Although Sun's ONC is in strong competion with Apollo's NCS,
the Apollo offering currently looks more suitable for us.
<LIHD> SPS Network Compiler
We have not succeded in getting specifications for the protocol
or message formats for this protocol, but it would be useful
for experiments to be able to exchange data this way with the accelerators,
without having two RPC systems on the same machine.
An alternative might be the port of our system to Unix machines, which we
envisage anyway.
In either case, the possibility always exists of a collaboration with
SPS/ACC group, depending on the pressures and leanings of the people
involved.
</UL>
<H1> Maintenance
A typical snapshot (08:30, 21&hyphen.Oct&hyphen.88) of tasks needing to
be done for existing systems is:
<UL>
<LI> RPC manual - minor updates.
<LI> RPC Internals guide - update for latest version, and C source.
<li> Version of entire library compiled for the M68020 [Valet]
<li> Bug: some conflict between TCS and CHI RPC. [L3 - Linnhofer]
</UL>
<h1>Gateway
<H1>Recent Upgrades
Features recently introduced have been:
<ul>
<li>TCP/IP working on Unix, OS9, VMS, IBM-PC
<li>Operation with the Internet daemon
<li>Operation with a name server (WAY) to help clients find servers.
<li>Handling of structures
</ul>
<H1> Conclusions

<h2>Effort required
The support of existing systems could currently occupy one full-time person.
This tends to decrease as the system becomes stable and well documented,
but increase as the system is extended.  However, it is the extent of the
environments and media over which RPC operates which gives it its usefulness,
and great gains are made from similarity of systems across the range.
With each new port, the effort required decreases, and the advantage gained
increases, so the emphasis must be on keeping the system available where
it is needed.

For the long term, the interworking of our system with the Apollo NCS system
should relieve us of the necessity to extend the RPC system onto an
unbounded set of machines. This requires a significant investment of effort,
though: Three person months should be enough to investigate the possibility,
and three more to make an implementation more solid. This would inevitably
lead to a certain amount of low-level support for NCS (pointing users in
the right direction).

A significant hole in the current system is that the compiler will not handle,
for example, structures. There is a long overdue list of extensions to the
compiler, largely arising from a general switch among users from FORTRAN to C.
This could be tackled on the surface in a week or two, and done thoroughly with
a month or two. (The compiler needs a lot of testing when any mods are done). 

<h2> People

The porting has so far been done by a variety of people, each involved with one
particular environment, while I have been doing the general support of the
kernel, coordination, and helping out when people have got stuck. I have
occasionally had time to add the odd new feature. This has been, in general,
very successful as a way of working, but has relied on occasional help from
other members of OC, the generosity of collaborations in providing effort, and
on a continuous stream of students. We might hope to be able to keep this up in
the future.

A very significant step is the port from OS9 to Unix, as this will give us
a solid base of C code supporting Unix-style operating sytems.  (The intention
is to use C in the future where possible rather than Pascal, although this
will not be possible everywhere). After the Unix port, ports to similar systems
should become increasingly easy, just as the pascal ports have become.
This side of the operation could, however, keep one person gainfully employed
full time for several months.  Because of the future potential of this step,
it would seem wise to use effort within the group if we can.

At the time of writing, we have no students working on RPC, and many things to
be done, and I am in the unfortunate position of having to turn down what seem
very reasonable requests from users inside and outside the group.
I therefore present this summary of the situation: that seven people could
easily and usefully be absorbed in the work to be done,
but that two or three at any one 
time could survive. One person is insufficient.
</BODY>
<LI> Convert documentation of compiler into 'man' form.
</GDOC>
