transactor.conf

mkdir -p /var/transactor
mkdir -p /var/transactor/tlog
:>/var/transactor/mlog
cat >/etc/transactor.conf <<EOF
logname "transactor"
logfacility ""
username ""
groupname ""
pidfile ""
signal_dumpfile "/tmp/transactor_dump"
server_port "127.0.0.1:2000"
server_max_clients 10
client_timeout_ms 0
client_keepalive_interval_ms 0
client_keepalive_timeout_ms 0
admin_port  "127.0.0.1:2001"
tlog_base_directory "/var/transactor/tlog"
mlog_file "/var/transactor/mlog"
local_node_name "A"
{
}
EOF
transactor -c /etc/transactor.conf


You can now test this configuration like that:


telnet localhost 2001
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
subscribe 1
status 1 0 majalive uptodate 0 1 not_started
post 17 1 "testdata"
post_response 17 posted 0:1 1
tlog_tspec tid 1 sid 0:1 size 8
testdata
quit
bye
Connection closed by foreign host.

#
# Sample Transactor Configuration File
#
# Copyright 2003 Claus Fischer
#

###
#   Syslog configuration
###
logname "transactor"
logfacility "local2"


###
#   Daemon configuration
###

# If transactor should switch to a particular uid/gid,
# put the uid or username in the string.
# Note that this happens before transactor opens its
# networking ports, so those ports should probably
# be above 1024.
username ""
groupname ""

# If transactor should write a pid-file, put the
# filename in the string.
#
# If transactor finds such a file on startup, and the
# process id in the file is that of a running process,
# it will refuse to start.
#
# Please use an absolute path.
pidfile ""


###
#   Transactor service
###

# If the transactor receives a SIGUSR1,SIGUSR2 or
# SIGHUP, it will dump the internal state to this
# file.
# If the filename is empty, it will not dump.
signal_dumpfile ""

# Transactor offers its service on a local port
# to other programs as clients.
#
# Note:
#
# Transactor is designed to handle serialization
# of transactions among multiple transactors
# participating in a distributed system.
#
# Transactor is NOT designed to serialize requests
# for multiple local clients efficiently. There
# are better methods available for that purpose
# on each operating system.
# If two or more local clients propose transactions
# simultaneously, transactor will work correctly
# and pick one specification, ultimately, as the
# winner, but a lot of obsolete transaction data
# might be sent across the network, wasting bandwidth.
#
# Therefore, it is strongly recommended that only
# one client be connected on each node where
# transactor runs. The client should handle
# serialization of incoming requests for transactions.
# If you use multiple clients, they should probably
# coordinate among themselves and pick one to propose
# the next transaction.
#
server_port "127.0.0.1:3101"
server_max_clients 10

# Client timeouts
#
# Those parameters define how the client is handled.
# The timeout applies only when data is due to be
# sent/received. The keepalive sends a "ping0 message
# that must be answered by a "pong0.
client_timeout_ms 10000
client_keepalive_interval_ms 300000
client_keepalive_timeout_ms 10000

# Admin port
#
# This port is for administrator access to the
# transactor during operation, to analyze or
# debug its behaviour.
# You can telnet to it, and say 'help' for more
# information. Many commands are the same as for
# the regular server port.
admin_port "127.0.0.1:3201"

# Transaction log
#
# The transaction log is an eternal log of all transaction
# data coordinated through transactor. It is organized in
# subdirectories under the tlog_base_directory, with 100
# files/directories at most in one directory.
# You may remove old transactions at your own risk; as long
# as all transactors on all nodes are beyond that transaction
# and no client will ever request the data, that is fine.
# You must not remove partial files.
# Note that before removing old files, you should change the
# search algorithm in tlog.c that identifies the last
# transaction in the tlog.
tlog_base_directory "/var/transactor/tlog"

# Message log
#
# The message log is a rotating log of currently relevant
# messages. It is purged on transactor startup, and then
# at times when it seems opportune. It may grow to very
# large sizes if large transactions are handled by the system.
# The directory holding it must allow for creation of new
# files, renaming and deleting of files, as the message
# log must be atomically replaced.
mlog_file "/var/transactor/mlog.dat"

###
#   Peer networking
###

# Peer-to-peer networking of transactors
#
# All transactor nodes use a short node name which must
# be known to all other nodes in the system. A transactor
# will typically use one UDP and one TCP port on the local
# system, and additional ephemeral TCP ports for outgoing
# connections as required.
# It is possible, though, to use a different local UDP or
# TCP port for each peer, since each transactor is connected
# with each other point-to-point. This is shown in the sample
# for peer d.
# The peers will be internally sorted by name (with strcmp()),
# then numbered from 0 upwards. For UDP, the connection is
# fully symmetric. For TCP, the peer with the lower index
# will connect, and the peer with the higher index will listen.
# Both TCP and UDP communication uses messages of up to roughly
# 5000 bytes. On networks that have a reasonably reliable UDP
# connectivity, this should be the preferrable transport.
# Transactor will handle the removal of duplicates, timeouts
# and retransmissions just fine, and UDP is more lightweight
# than TCP.
# Networks with limited packet size are expected to perform
# proper path MTU discovery on the UDP ports (the sockets are
# bound and connected so that both addresses are known to the
# OS). However, there may be many situations in the real world
# where UDP messaging does not work well with larger packets,
# or UDP should not be used at all. For this purposes, a
# maximum UDP message size can be specified; if it is set to 0,
# all messages will be sent over TCP.
# To encrypt the packets sent and received, specify an
# encryption_key. This key should have at least 50-60 characters.
# From this key, a 256 bit field for AES encryption will be
# generated.

local_node_name a
tcp "127.0.0.1:3001"
udp "127.0.0.1:3001"
{
    peer b
        tcp "127.0.0.2:3002"
        udp "127.0.0.2:3002"
        udp_maxsize 10000
    peer c
        tcp "127.0.0.3:3003"
        udp "127.0.0.3:3003"
        udp_maxsize 10000
     # Use encrypted connection to c
     encryption_key
           "blablaepfoah;gaghaighawiughagiahgaighaewrighargiawge"
    peer d
        # Local ports to use specifically for this connection
        local tcp "127.0.0.1:3001"
        local udp "127.0.0.1:3001"
        tcp "127.0.0.4:3004"
        udp "127.0.0.4:3004"
        udp_maxsize 10000
    peer e
        tcp "127.0.0.5:3005"
        udp "127.0.0.5:3005"
        # UDP to this peer is unreliable
        udp_maxsize 0
}

# Since the above configuration uses five nodes, a minimum of
# three must be alive to get the system going.

# How to change peers:
#
# Note that once the peer list is defined, it should not be
# changed. The problem is in the message log, which contains
# messages from all peers and relies on proper peer indexing.
#
# If the peer configuration should be changed, all clients
# should be disconnected from the transactors, then the
# transactors should be given enough time (and a working network)
# to finish the last transaction before being shut down.
# Finally, the message logs of all nodes should be emptied.
#
# After startup, the transactors will restart numbering
# specifications with sid's of 1 upwards. That should not be
# a problem, as the value of the sid is irrelevant once the
# transaction is completed.