-# We assume three type of connections
-# SERVER we know the local port P, and do the
-# bind/listen/accept on the local socket.
-# pipe_in in dst-port P
-# pipe_out out src-port P
-#
-# CLIENT we know the remote port P, and do a connect to it
-# (src and dst are swapped wrt the previous case)
-# pipe_in in src-port P
-# pipe_out out dst-port P
-#
-# SERVICE we run a server on local port P, and also connect
-# from local clients to remote servers on port P.
-# pipe_in in { dst-port P or src-port P }
-# pipe_out out { src-port P or dst-port P }
-#
-# On a given port a user can have one CLIENT and/or one SERVER
-# configuration or one SERVICE configuration.
-# When a SERVICE configuration is installed any existing CLIENT
-# and SERVER configuration on the same port are removed.
-# When a CLIENT or SERVER configuration is installed any existing
-# SERVICE configuration on the same port is removed.
-#
-# The following is a case that is implemented as SERVER
-# D we run a server on local port P, and also connect
-# to remote servers but doing a bind(P) before connect().
-# In terms of rules, this is not distinguishable from
-# the SERVER case, however it would be different if we
-# had a way to tell SERVER from CLIENT sockets
-# pipe_in in dst-port P
-# pipe_out out src-port P
-#
-# The database of current ipfw and dummynet configuration is in a
-# file which is regenerated on errors. The format is
-#
-# slice_id type arg rule_base pipe_base timeout
-#
-# (lines starting with '#' are comments and are ignored)
-# For each configuration we allocate one rule number in ipfw,
-# and two sequential pipe numbers.
-
-# globals, do not touch below