NobleNet's EZ-RPC makes it much easier to build distributed client/server applications--from scratch or from existing stand-alone programs
Ben Smith
C language application programmers are seldom network communications programmers. They may understand the concept of client/server applications, but they typically lack the know-how to implement them over heterogeneous networks. NobleNet's new RPC toolkit EZ-RPC gives programmers the ability to write transport-independent client/server applications without network programming skills. EZ-RPC shields you from the network connection, making calls to routines on other systems seem no different than calls to local C functions.
Just a few years ago, typical client/server applications resided wholly within a single multitasking computer. The server and clients ran a
s separate processes and communicated using operating-system services such as semaphores, shared memory, messages, or named pipes. Today, there's usually a network between client and server processes, and the two can be running on different computers, processors, and even operating systems. While the application may remain the same, implementation has become much more complex, because the old IPC (interprocess communications) methods have no meaning when there is no shared memory or file space.
Enter RPC
IPC over networks is typically handled with sockets, but socket programming isn't trivial. It follows a file I/O model and becomes tedious with anything more complex than a simple data stream. To hide the complexity of socket programming, communications programmers developed an interface for building IPC that mimics the structure of a simple C function call--a function's name, its arguments when called, and its returned value or structure. This method of communication is known as a remote procedure
call, or RPC. Apollo's NCA (Network Computing Architecture), Xerox's Courier, and Sun Microsystems' ONC (Open Network Computing) have each provided RPC programming tools and libraries.
ONC includes Sun's XDR (cross-platform data representation), which allows little-endian computers, such as Intel-based systems and DEC VAXes, to transparently exchange data with big-endian computers like IBM mainframes and Apple Macs. Now, nearly every Unix applications developer's license includes ONC RPC, NFS/ RPC, or the newer operating-system-independent TI/RPC. Open Software Foundation's DCE/RPC, a descendent of Apollo's NCA, hasn't been as widely accepted.
The EZ Advantage
Although RPC simplifies IPC, most RPC toolkits have limits to their abilities to disguise client/server interactions as simple C functions. EZ-RPC overcomes almost all of them (see the table "Advantages of EZ-RPC"). EZ-RPC's most significant feature is that, with few exceptions, it lets you use all standard C argument constructs, variab
le dereferencing (i.e., use of addresses and pointers), and data structures.
Other toolkits limit you to a single argument and to simple data types that can cross easily between client and server. In other words, you still have to write specially constructed functions for any services that span the connection between client and server. With EZ-RPC, you don't need to rewrite existing functions when creating a client/server application from an existing stand-alone program. Nor do you need to constrain function design if you are developing a new application with distributed computing in mind.
To use NobleNet's RPC development tools, you break the client and server parts of an application into separate compilation file lists. You then define the functions that bridge the client and server in an RPC specification file, run the rpcgen utility that generates the supporting source files, and compile the resulting client and server parts of the code, linking them with the RPC library calls that are made
in the generated code.
With EZ-RPC, the only necessary addition to your source code is a single function call that your client program must make to establish communications with the server; myprogram_open_transport(argv[1],0,0); is an example. But there are a few C language ambiguities that you should resolve. The most common is the use of the construct char * as the generic notation for a pointer to any data type. EZ-RPC provides predefined data types that you should use instead to resolve data-structure ambiguities.
The RPC specification file that you must build has a syntax similar to C's. It contains a program specification that holds the information about each server function made available to the clients, plus the data types of these functions and their arguments. The EZ-RPC specification file uses the same format as the TI/RPC or NFS/RPC specifications, with a few enhancements. Each function argument specification contains a modifier (in square brackets) that describes in which direction
the data is to flow with the argument.
Besides enhancements for resolving ambiguities, EZ-RPC has advanced features for creating complex client/server applications. These include client-broadcast RPCs and, for applications that use multiple servers, find_server and collect_ servers functions. You can also create callback programs in which the client and the server switch roles.
Testing Its Metal
To evaluate EZ-RPC, I started with source code from a configurable command interpreter I'm building, a stand-alone application that creates a binary tree. I divided the code in an unlikely way (from a client/server standpoint) that forced the client and server to pass the tree back and forth between them. With a single-process, stand-alone application, it makes sense to use pointers. But a pointer to an address in a process on one system has no meaning to another process on another system.
In spite of the inherent difficulties, EZ-RPC easily built the communications stubs that allowed my client
and server to continue using these complex structures. This was a particularly challenging task because the size of the shared data structure wasn't available until the functions that generated the tree were complete. (It would have been a nightmare to try to build the data communications with sockets, or, for that matter, with shared memory, semaphores, and named pipes.)
The problems I ran into using EZ-RPC were not in its design and function, which are very robust, but in understanding the syntax of RPC specification files. Even though NobleNet's manuals explain basic concepts well and go into considerable detail with extensive examples, there are some picky syntactical requirements that need greater emphasis. Misunderstanding them delayed me in getting my application to compile and run properly. Fortunately, NobleNet's technical-support team set me straight, without confusion or delay.
Beyond Unix
I evaluated NobleNet's Unix product, EZ-RPC, but network IPC is not limited to the Unix envi
ronment, and neither are NobleNet's products. You can provide DOS/Windows applications with client/server capabilities using WinRPC ($995), which generates WinSock-compliant RPC DLLs. RPCWare ($4995) does the same for NetWare clients and servers, generating C source stubs for EXEs and NLMs (NetWare loadable modules). And programs developed in the Windows environment, for example, can communicate transparently with client or server code that you build in the Unix or Novell environment.
EZ-RPC supports Unix implementations from Sun, Hewlett-Packard, DEC, Silicon Graphics, IBM, The Santa Cruz Operation, Data General, and Next. Licensing of the first seat for either EZ-RPC or RPCWare is $4995 on the server side; the price decreases for additional seats. This may seem steep to a PC developer, but there is no licensing for code generated by these products, nor for including NobleNet's libraries in the executables you link and distribute.
I found EZ-RPC to be an easy-to-use tool valuable for converting
any appropriate application program to a network-based client/server design, and it doesn't require an understanding of network programming. What EZ-RPC will not do is claw apart your application into client and server components; you have to perform this onerous task by hand. However, because EZ-RPC makes it so easy to move functions between the client and server sides, design iterations are painless.
Whether you're converting an existing program or building a new distributed application, EZ-RPC is a valuable tool for creating robust, well-behaved communications links. NobleNet's RPC tools let you build client/server applications that run on almost all Unix platforms, and, with NetWare and Windows, all from source code with no built-in communications. These distributed-application tools are far more economical and expedient than hiring or training communications experts to build distributed applications.
The Facts
EZ-RPC
$4995 for first platform, first seat;
$1495 for
additional platforms;
$495 for additional seats.
No fee on use of the libraries.
NobleNet, Inc.
337 Turnpike Rd.
Southboro, MA 01772
(508) 460-8222
fax: (508) 460-3456
Advantages of EZ-RPC
EZ-RPC
PARAMETER PASSING
Places no arbitrary limit on the argument list.
DATA TYPES SUPPORTED
Supports all data types (including pointers) and structures, except those that cannot be fully resolved to having a beginning and an end (e.g., doubly linked lists and rings).
TRANSPORT PROTOCOL
Is built on top of TI/RPC, and so is transport independent. A command-line option produces NFS/RPC calls.
RPC SPECIFICATION FILE
Provides extensive predefined data types and other enhancements for resolving ambiguities. Can read external header files to understand structures and data type definitions.
MEMORY MANAGEMENT
Has client and server memory allocation and memory management that are controlled by the state of the RPC call using it.
DOCUMENTATION
A 290-page manual docum
ents application-building with many examples, a thorough reference section on the RPC specification files, a description of generated files, and debugging methods.
OTHER RPC TOOLKITS
PARAMETER PASSING
Allows only a single argument and a single result. Multiple arguments or return values must be packaged as a structure.
DATA TYPES SUPPORTED
Supports only integer, floating-point, enumeration, structure, fixed-length and variable-length single-dimension arrays, and discriminated union. (DCE/RPC supports a few more.)
TRANSPORT PROTOCOL
Uses NFS/RPC, which is limited to either UDP or TCP and is not transport independent.
RPC SPECIFICATION FILE
Can't resolve data type ambiguities. Cannot read external header files to find data structures.
MEMORY MANAGEMENT
Has no memory management functions triggered by the state of RPCs, so memory "leaks" are hard to avoid.
DOCUMENTATION
Information is fragmented among several books, technical papers, and Unix manual entries.
Illustratio
n: Using EZ-RPC
Building a client/server application with EZ-RPC requires little more than dividing your C code into client and server portions and specifying which functions bridge the client/server gap. You don't need to rewrite existing functions or constrain design of new functions.
Ben Smith is a testing editor for the BYTE Lab. You can reach him on the Internet at ben@ bytepb .byte.com or on BIX as "bensmith."
Client/Server Made Easy
