summaryrefslogtreecommitdiffstats
path: root/usr.sbin/sendmail/contrib/xla/README
diff options
context:
space:
mode:
Diffstat (limited to 'usr.sbin/sendmail/contrib/xla/README')
-rw-r--r--usr.sbin/sendmail/contrib/xla/README207
1 files changed, 207 insertions, 0 deletions
diff --git a/usr.sbin/sendmail/contrib/xla/README b/usr.sbin/sendmail/contrib/xla/README
new file mode 100644
index 0000000..a72fd03
--- /dev/null
+++ b/usr.sbin/sendmail/contrib/xla/README
@@ -0,0 +1,207 @@
+ XLA - Extended Load Average design for Sendmail R6
+ --------------------------------------------------
+
+ Christophe Wolfhugel - Herve Schauer Consultants
+ wolf@grasp.insa-lyon.fr, wolf@hsc-sec.fr
+
+
+WARNING: this extension is supplied as a contribution to Sendmail.
+Should you have trouble, questions, please contact me directly, and
+*not* the Sendmail development team.
+
+
+ABSTRACT
+
+Sendmail currently furnishes a limitation mecanism which is based on
+the system load average, when available. Experience has prooven that
+this was not sufficiant for some particular situations, for example
+if you have slow and/or overloaded links. This can easily cause both
+system and network congestions with Sendmail having to handle a large
+number of simultaneous sessions on the same overloaded link, causing
+most of the SMTP sessions to timeout after a long time. The system
+load average is also generally too slow to react when your system
+gets a burst of incoming or outgoing SMTP sessions which on some
+stations can easily cause system unavailabilities.
+
+The extended load average module has been designed in order to furnish
+a way of limitation the load generated by Sendmail to both your
+system and your network. This design can be used either alone or as
+complementary to the system load average if your system supports it.
+
+Limitation is based on the number of incoming/outgoing SMTP sessions,
+and remote hosts are classified in classes. The system administrator
+will define a maximum number of incoming SMTP sessions as well as
+a maximum total (incoming + outgoing) sessions for each class of
+hosts. A class can be either an individual machine or a network.
+
+When the limit is reached for a given class, all incoming SMTP
+connections will be politely refused. When the limit is reached for
+all classes, the SMTP connections will be refused by the system
+(which one could consider as less politely :)).
+On outgoing mail, messages will be queued for delayed processing.
+
+The extended load average parameters are given in the Sendmail
+configuration file, and when not present, Sendmail behaves the
+usual way.
+
+
+COMPILATION
+
+Copy the xla.c module in the src sub-directory, edit the Makefile
+in order to define XLA (-DXLA). Also add the xla.[co] module name
+in the list of files so that it gets compiled.
+
+Regenerate sendmail by removing all objects, or at least those
+containing references to XLA (this list may vary, so use grep to
+get the module list). This will generate a new sendmail executable
+containing the xla code.
+
+Debugging level 59 has been assigned to this module and when used
+it provides some output (sendmail -d59.x). Please check the source
+code to see which levels are supported.
+
+
+CONFIGURATION
+
+The extended average uses a new set of configuration lines in the
+sendmail.cf file. All newly introduced line begin with the letter L
+(capital L).
+
+Before detailling the syntax, first an example (this can be placed
+at any section of the sendmail.cf file, note that the order is
+important). Fields are separated by (one or more) tabs/spaces.
+
+# File name used to store the counters
+L/etc/sendmail.la
+# Classes definition
+# Lname #queue #reject
+L*.insa-lyon.fr 8 3
+L*.univ-lyon1.fr 6 4
+L* 15 16
+
+The first line defines the working file which will be used in order
+to have the occurences of Sendmail read and update the counters. The
+format of this file is described in the "Design" section.
+This line is mandatory and the specified file must be absolute (ie
+begin with a slash).
+
+Then you can specify one or more classes. The last class (*) is also
+mandatory and should be in last position as the first match will stop
+the search and if there is no match the behavior of Sendmail is unknown.
+
+Each class has three fields separated by one or more tabs/spaces.
+
+L{mask} {queue_#} {refuse_#}
+
+The {mask} is a simple mask. It can be either an explicit host name
+(like grasp.insa-lyon.fr) or a mask starting with "*." or just "*".
+No other variants are allowed.
+
+Lgrasp.insa-lyon.fr will match exactely any session to/from this host.
+
+L*.insa-lyon.fr will match any session to/from any machine in the
+ insa-lyon.fr domain as well as from the machine
+ named "insa-lyon.fr" if it exists.
+
+L* will match any session, and thus should also be
+ last in the list to act as a catchup line.
+
+The {queue_#} is the maximum number of SMTP sessions in the given class
+for both incoming and outgoing messages. The {refuse_#} indicates when
+to refuse incoming messages for this class. The interaction between
+those counters is somewhat subtle. It seems logical that a standard
+configuration has {queue_#} >= {refuse_#}, and in fact in most
+configurations they can be equal (that's why what I use in my environment).
+Thus, this is not mandatory. If {queue_#} < {refuse_#} outgoing messages
+will be lower priority than incoming messages and once a class gets loaded
+the outgoing messages are blocked first.
+
+I use very low values in some situations, for example I have a customer
+connected to the Internet via a 9600 bps line, they also have internal
+users sending burst of messages (10, 20 small messages coming in just
+one or two seconds). Both situations were unsupportable. The line is
+too slow to handle many simultaneous connections and the mail server
+does not have the ressources to handle such a heavy load (it's a 12 Megs
+Sun 3 also doing Usenet news).
+
+I have defined following section in the configuration file, and experience
+shows the benefits for everyone. Fake domain for the example: customer.fr.
+
+L/etc/sendmail.la
+L*.customer.fr 8 8
+L* 3 3
+
+This means that there might not be more than 8 simultaneous SMTP sessions
+between the mail server and any other internal host. This is to protect
+the station from heavy loads like users (or applications !) sending
+several tenths of messages in just a few seconds).
+No more than 3 SMTP sessions are authorized with any other host, this is
+to save the load of the slow 9600 line to the Internet.
+
+Drawback is that is you have 3 * 2 Megs sessions established from/to the
+outside, all your mail will be held until one slot gets available, on
+a 9600 bps line just make your counts, il blocks your line during over
+one hour.
+
+
+DESIGN
+
+Sendmail will analyze the "L" lines in the configuration file during
+startup (or read the initialized structure from the frozen file).
+When started in daemon mode (and only there), any existing working file
+will be cleared and a new one is created. Each class gets a record in
+the sendmail.la work file. The size of this record is a short integer
+(generally two bytes) and represents the count of active sessions in
+the given class. Read/Write operations in this file are done in
+one operation (as anyway the size is far below one disk sector). The
+file is locked with Sendmail's lockfile() function priori to any
+access.
+
+Handling incoming SMTP sessions.
+
+There is interaction is two points in the Sendmail source code. First
+on the listen system call: if all slots in all classes are in use,
+a listen(0) is done so that the system rejects any incoming SMTP session.
+This avois to fork and then reject the connexion.
+
+If there are some free slots, nothing better than accepting the
+connection, then forking can be done. The child process then checks if
+the adequate class is full or not. If full, it rejects the connection
+with a "421 Too many sessions" diagnostic to the sender (which should
+then appear when the remote users do a mailq). If the treshold {reject_#}
+is not reached, the connection is accepted and the counter is sendmail.la
+is updated.
+
+Handling outgoing SMTP sessions.
+
+As soon as Sendmail needs to connect to a distant host, the adequate class
+is checked against {queue_#} and if no slots are available, the message is
+queued for further processing.
+
+Sendmail's connection caching.
+
+Sendmail-R6 introduces a new design: connection caching, ie several SMTP
+sessions can be opened at the same time. This could cause some problems
+when sending mail, as after having a few connections opened, all slots
+could be in use and generate a partial delivery of the message. In
+order to deal with this, xla.c uses following design "for a given
+sendmail process, only the first connection in a given class is counted".
+This can be done because sendmail does not do parralel message sending
+on the different channels.
+
+End of connection.
+
+As soon as a connection is closed, the counters will be automatically
+updated.
+
+
+
+Please look at the code to understand of all this works. Comments,
+suggestions, questions welcome.
+
+
+
+ Christophe Wolfhugel
+ Herve Schauer Consultants
+ Paris, France
+ May 23, 1993
OpenPOWER on IntegriCloud