This is a simple, generic tcp based server for allowing access to multiple server processes. It's very simply configurable, and can serve up multiple processes. I know this descirption sucks, and I'll post a better one RSNtm. For now, here's the README:
tcp_server -- A simple, generic tcp based server.
Copyright/General Information
-----------------------------
Copyright 1998 Kyle R. Burton, All Rights Reserved
Email: mortis@voicenet.com
Web: http://www.voicenet.com/~mortis/
This package can be freely distributed and used under the terms of the
GNU General Public License, either version 2 or (at your opinion) any later
version. See file COPYING in any of GNU packages or look at http://www.gnu.org/
for more detains on the GNU project.
Send all comments and suggestions to the author:
Kyle R. Burton mortis@voicenet.com
(I'd love to know if/how you're using this code)
The most recent version(s) can currently be obtained from:
http://www.voicenet.com/~mortis/projects/tcp_server/
A speical thanks has to go out to Martin Mares
from whom I lifted the technique for tying the socket file descriptors
to stdin/stdout/stderr.
Thanks Martin
Synopsis
--------
This program provides a server that listens on a tcp socket, takes the
first line of input from the client connection, and execs a predefined
process to handle the connection. It ties the input/output of the handler
process to the socket. This makes writing the handler processes extrememly
simple -- all they need to do is read from standard in, and write to standard
out. This even allows you to use anything that can use stdin/stdout to
handle the connections, this includes: shell scripts, perl, python, lisp,
C, C++, pascal, assembler, basic, expect, fortran, and just about any other
programming language you can think of.
Building the software
---------------------
First off, you'll need to get my library: o'lib. You can get it from:
http://www.voicenet.com/~mortis/projects/olib. Untar it into it's own
directory. The best way to do this is at the same directory level that
you put tcp_sever at. If you unarchive tcp_server in a directory
/stuff, you'll end up with /stuff/tcp_server, unarchive olib in the
same place, so you end up with /stuff/olib.
All the code should be pretty much platform independant. There are two
makefiles provided. Once is for g++ under Linux, and the other is for
aCC under HP-UX. You can probably just edit the makefile.conf to set
OLIB_PATH to where you put olib, and then execute either:
[you@your_box src] make -f makefile.linux
or:
[you@some_hp_box src] make -f makefile.hpux
Depending on what platform you're on. As far as other platforms go...I
don't have access to anything else, and I (so far) don't have any
experience with autoconf or any of it's derivatives.
Testing the software
--------------------
This distribution should contain two sample protocol handlers, echo.pl,
and echo_server. These both perform just about the same functionality,
which is to spit back whaever the client sends them. You can test the
server by running it, telnet'ing to your machine on port 4137, typing
echo_server (followed by enter), and playing with it interactivly.
This should also make the 'protocol handlers' very easy to debug, as
you can just run them from the command line (no need to run them from
inside tcp_server to test/debug them). See the files tcp_server.conf,
and protocol_handlers.conf for more information.
Writing a Protocol Handler
--------------------------
Just make something that reads from stdin, and writes to stdout!
You will need to write exactly zero lines of socket code.
Problems/General Issues
----------------------------
Q: Why won't tcp_server/olib compile under compiler X?
A:
I've only tested it under the egcs version of g++: egcs-2.90.27 under
linux, and aCC under HP-UX,. From what I know of usign some other compilers
(like g++ v2.7.2) is that they lack the ability to properly generate the
specializations for the template code.
Q: Why does the bind step always fail for ports < 1024?
A:
You need to be root to run a process that binds to a port less than 1024.
This is a restriction imposed by the OS, and is for security reasons.
tcp_server is not necessarily in and of itself insecure, but I wouldn't
personaly run it on any of the standard ports...