support library for servers

From: Joerg Wittenberger <joerg.wittenberger_at_nospam.org>
Date: Tue Dec 27 1994 - 09:51:02 PST

Hi,

I started a support library for servers. At the moment it makes it a
lot easier to write servers. But it still far from being complete.

For testing I converted tmpfs to use this library and wrote a server
which only passes the received messages to another server (acts
simillar to a simple mount, but it leaves all permission checks out).
I don't expect it to be usefull as it is, but is a good template for
real servers so I'll append it as a example)

I enclose the README and the server.h which holds all the current
documentation. If someone is interested mail me for the code or try to
get it from

http://ibch01.inf.tu-dresden.de:8001/people/jw/vsta/v132/srv/lib/

(But I am behind the slowest line you may think of.)

---- The README ----
This is a support library for servers.

It implements a abstraction of what a server is. This is independent
of the underlying OS. (Actually only implemented for VSTa, should be
easy for QNX and L3 -- this is what I know, and almost anything else.)

See "server.h" for Details of the provided abstraction.

At top of this interface it becomes much more easy to write a server.
Beside the system independence you get, some of the edge cases
disappear (because you don't see the message interface). Furthermore
the name handling becomes uniformed.

libc/statsup.c is copied and adapted. (Unfortunately it does some msg_
actions itself.)

Side note:

This code could benefit from a proposed kernel service
msg_send_and_receive. As long as kernel entry is that expensive as on
the intel it would save a lot of execution time.

TODO:

* Think about a VSTa independend "struct msg".

* Add support for multithreaded servers. (currently a matter of the
server specific code).

* Fix the hackery around the unknown value of the M_READ bit.

* improve the service selection on a received message. (As long as
VSTa needs about 10-20 the time of similar systems for a context
switch it doesn't matter.)

Contact:

joerg.wittenberger@inf.tu-dresden.de

----- server.h ------
#ifndef __SERVER_H
#define __SERVER_H

/*
 * server.h
 *
 * REASONING
 * This implements a abstraction of what a server is.
 * A server build at top of this interface is not VSTa specific in
 * respect to the interface it serves. (It may be VSTa specific in the
 * sense of being a client of another server.)
 *
 * A server consists of a set of services (functions of the type
 * service) which are bound to a message. These functions all act
 * on a received message and a data structure associated with the
 * client. They return a NULL pointer on success or a pointer to a
 * error string on failure. On success the message is modified to be
 * used as the reply message.
 *
 * One may think about the mentioned data structure as a object served
 * and the functions as methods on this object (and the message as
 * arguments to this method).
 *
 * Every server has to provide a function init_server (and no main!)
 * which does all startup initialization of it's internal data
 * structures and even so establish connections to servers it uses.
 * It does NOT establish any namer_registration. (The name to use for
 * registration is the first argument to the server, but this is a
 * VSTa specific issue.)
 *
 * There should are a special function to generate and initialize a
 * new data structure (ignoring the provided pointer) which is usually
 * bound to the M_CONNECT (under VSTa) and acts as the constructor in
 * the sense of object orientation, a function to copy a object from
 * another one (usually bound to the M_DUP) which may be seen as the
 * constructor with a object to copy and also a function which deletes
 * such a object (usually on M_DISCONNECT), the destructor. A function
 * which successfully created a new object (file in the sense of VSTa)
 * should bind it to a client. All functions bound to successive
 * messages from this client will act on this object. A binding gets
 * revoked by a call to the bindclient with the same id but a NULL
 * pointer as object.
 *
 */

/*
 * import "struct msg"
 */
#include <sys/msg.h>

typedef char* (service)(struct msg *, void *);

extern service* server_bindfn(int, service*); /* Bind function */
extern service* server_bindfn_dft(service*); /* (Re)bind the default */
extern void* server_bindclient(int, void*); /* bind client */

#ifdef WITH_PASSMSG

/*
 * If WITH_PASSMSG is defined, the server has support for
 * server_passmsg to pass a message on to another server. This is
 * conditional compiled because of the questionable design of VSTa,
 * which hides the M_READ bit while it doesn't provide a abstraction
 * of it. So we have to do some hackery to find the correct meaning.
 */

extern char* server_passmsg(port_t, struct msg *);
#endif

extern int init_server(int argc, char **argv); /* supplied by client */

/*
 * server_mmalloc
 *
 * some servers like to malloc buffers which have to be free'd after
 * the msg_reply (in VSTa, generally spoken which live as long as the
 * message is processed), but no service will ever see this point.
 * Such buffers are malloc'ed by server_mmalloc with the corresponding
 * struct msg. They are automatic free'd.
 *
 * This is a bit dangerous because of possible missuse: Never use this
 * function with a other "struct msg" except the one in the arg (and
 * only in servers which are at top of this interface). Also don't use
 * it for buffers which are kept anywhere else (like the per client
 * data)!
 *
 * It is usefull for all dynamic buffers in a service. Never
 * free it yourself! Even never try to send back static buffers use
 * buffers you got from this function!
 *
 */

extern void* server_mmalloc(struct msg *,long);

#ifdef DEBUG
/*
 * Set this to 1 if you like to get some syslog-info from the
 * server.c. But only if this is also compiled with DEBUG.
 */
extern int server_dbg_flag;
#endif

#endif /* __SERVER_H */

/Joerg

-----------------------------------------------------------------------------
Joerg Wittenberger | email: joerg.wittenberger@inf.tu-dresden.de
Rietzstr. 32b |
01139 Dresden |
Germany | PGP: D4 B2 DA AE C3 02 50 9C 45 3E AD 99 C1 1A 8E F8

WWW: <a href=http://www.inf.tu-dresden.de:~jw6/top.html> (click here) </a>
Received on Tue Dec 27 17:16:53 1994

This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:11 PDT