The best way to write a server from scratch is probably by using the TINE server wizard. The next best way is to make a copy of a working server and then make modifications to suite the needed functionality. To this end it is instructive to follow the Build Recipe outlined below. Note that the build instructions apply to Solaris, HP-UX, SGI, OSF, Linux, FreeBSD.

1. Make a directory on your machine called tine. This could be for example /home/joe/tine.
   Locate the TINE distribution, and via ftp copy all files in kernel/source to the tine directory. For example:

cd /home/joe/tine
ftp mkinthera1
ftp> cd hera/kernel/source
ftp> prompt
ftp> asc
ftp> mget *

1. Go to your platform in the TINE distribution. For example, suppose you are making a LINUX server or client, go to kernel/source/Platform/linux. You should simply get all make files you see. You’ll end up with the following make files:
   

• libtine.mak: which makes a library with all TINE modules bound together except the application specific modules
• libtinemt.mak: same as above but for a multithreaded build.
• fec.mak: a client-server example which uses the library made from the libtine.mak file
• clntools.mak: which makes various client command line tools such as tget, tmonitor, tprops, etc.
• remote.mak: which makes the contact program for a server running in the background.
  
• trepeater.mak: which makes a Tine repeater server
• wizard.mak: which makes a server setup wizard

You will also get a copy of the platform specific “project.def” for your target platform. The make file itself is also platform specific in that it contains all appropriate compile switches for the platform in question. For example (same ftp session as above):

ftp> cd platform/linux
ftp> mget *

1. Go the examples directory directly under source/ and get all of the example source modules you see:

ftp> cd ../../example
ftp> mget *

1. Get out of ftp and make the library libtine.a by typing:

make –f libtine.mak

1. Make a working directory for your server (or client). For example “/home/joe/rpcserv”. Copy the files rpcserv.c, sinsrv.c and fec.mak as well as all .csv files from the TINE/lib directory to this directory:

cp /home/joe/tine/rpcserv.c ~/rpcserv/
cp / home/joe/tine/sinsrv.c ~/rpcserv/
cp / home/joe/tine/fec.mak ~/rpcserv/
cp / home/joe/tine/*.csv ~/rpcserv/

1. Edit the make file fec.mak so that the paths shown for the LIBS and INCL symbols reflect the location you wish to chose. You could simply leave everything in the tine directory. The suggestion is to make (as root) a directory /usr/include/tine and to copy all of the *.h and *.def files there, and then to copy all of the lib files *.a to /usr/lib.
   

cp *.h /usr/include/tine/
cp project.def /usr/include/tine/
cp *.a /usr/lib/

1. Finally, make the fec.mak file:

make –f fec.mak

1. Edit the file fecid.csv and give your server a more meaningful (albeit unique) server name than “MYFEC”
2. Edit the file exports.csv and make sure all references to “MYSINE” are likewise changed to something more meaningful (but nonetheless system-wide unique).
3. Run the freshly created server program rpcserv. If an equipment name-server (ENS) is configured and running, this server will automatically plug itself into the system-wide database. If an ENS is not running, then you will have to modify database entries by hand to include the address and name information pertaining to your server. If this is the case, you’ll have a lot of hand-work to do, and it is strongly advised that you configure a equipment name server as soon as possible. Ultimately, you will want to run your program in the background. When you do this, be sure to pipe in the null device as standard input and standard output, as in

rpcserv </dev/null >/dev/null &

1. You have full control over the contents of the files copied to the working directory (in this example) /home/joe/rpcserv. In particular, you will probably want to edit (if not change the module name) sinsrv.c to meet your needs. You may not have to touch rpcserv.c at all, but you can if you need to add something to the main loop

Comments:

You can also make the debug library libtineg.a using libtineg.mak and the corresponding ipx libraries libtinex.a and libtinexg.a (which work only if the IPX stack is loaded on your UNIX machine). You can also work entirely from the source modules if you prefer. In general, you should not touch any of the modules found in the ../source distribution subdirectory.

If you have installed the tine debian package, then you will already have the TINE library files (libtine.a, libtineag.a, libtinex.a, libtinexg.a, libtinemt.a, libtinemtg.a, libtine.so, libtinemt.so) in the /usr/lib directory, as well as the include files in the /usr/include/tine directory.

The above is a step-by-step recipe for getting the example server and client programs to run. You may prefer to work with the server wizard to produce your first working example of a TINE server. The wizard will generate code as well as make files which will produce a running server application (happily simulating data). The wizard generated make files assume that the tine library and include files are (as noted above) in /usr/lib and /usr/include/tine respectively.

Servers running in the background can be accessed through a named pipe via the ‘remote’ program. You can build the project by typing make –f remote.mak from within the tine subdirectory you created above. A server creates a pipe in the /tmp with the name <FECNAME>.ipc and write permission for the user who starts the server. The remote program the attaches to this pipe to allow command line access to the server.

To start a remote session, you would type

remote <FECNAME>

where <FECNAME> is the FEC name of the running server.