httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Generalising Connections
Date Sun, 17 Dec 1995 12:12:54 GMT
Just goes to show how bad my hangover was - I forgot to write about the second
part of the subject.

As I have mentioned before, the problem with Apache and modules which want to
take over the data transport, is that Apache knows that a connection is a file
descriptor. This is not generally true - especially under non-Unix OSes, where
typically even a plain ordinary TCP/IP connection is not a file descriptor.

Making connections totally generalised is a non-trivial task, but there is at
least one thing that is clear: the "client" and "request_in" members of
conn_rec must go (see httpd.h). This implies that all functions that use them
need changing, and all low-level functionality (e.g. read, write, open, close)
must be supplied in a modular way.

This is, of course, similar to the way that modules work, but not quite the
same; the function table should be associated with each connection (this
allows dynamic matching of transports to connection, and layering), rather
than being part of a static list.

I propose a scheme along these lines; we have a transport function table:

typedef struct connection connection;
typedef struct transport_fn_table transport_fn_table;

struct transport_fn_table
	{
	int (*write)(connection *conn,const char *buf,int n);
	int (*read)(connection *conn,char *buf,int n);
/* etc... */
	};

client and request_in in conn_rec are replaced by:

	connection *conn;

and a connection looks like:

struct connection
	{
	void *info;	// private data for the particular type of connection
	transport_fn_table *fn;
	};

Simple, huh? Add a few macros, and the whole thing is (nearly) transparent to
the ordinary module, for example:

#define conn_write(conn,buf,n)	(conn)->fn->write(conn,buf,n)

Of course, C++ fans will note how much neater this would be in C++.

The reason I intended to write about this in conjunction with CVS is simple;
with the patch and vote system it could take a long and painful time to get
this change in. It'll be a good test of the efficacy of CVS trying to get such
a global change done.

Let me know what you think.

Cheers,

Ben.

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant        Fax:   +44 (181) 994 6472
and Technical Director      Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Mime
View raw message