#ifndef _PARAMS_H_8b1b0f28_
#define _PARAMS_H_8b1b0f28_

/* This file is in the public domain. */

/* Protocol `parameter' constants. */

/* This is more generous than the spec says we need to be; it says 255
   including the trailing CRLF.  Our max doesn't include the CRLF. */
#define SSH_MAX_VERSION_LEN 256

/* Max size of a packet on the wire (after compression and encryption and
   adding the leading/trailing goop).  The spec says this must be >=35000. */
#define SSH_MAX_PACKET_LEN 40000

/* Max size of a packet payload, in the uncompressed clear.
   The spec says this must be >=32768. */
#define SSH_MAX_PAYLOAD_LEN 35000

/*
 * This value is what we put in the "maximum packet size" field of
 *  CHANNEL_OPEN and CHANNEL_OPEN_CONFIRMATION messages we generate.
 *  This is documented as
 *	The 'maximum packet size' specifies the maximum size of an
 *	individual data packet that can be sent to the sender.
 *  There is disagreement over exactly what this means.  It seems to me
 *  that this means "the maximum size of a CHANNEL_DATA or
 *  CHANNEL_EXTENDED_DATA message", but at least two other
 *  implementations take it to mean "the maximum size of a CHANNEL_DATA
 *  or CHANNEL_EXTENDED_DATA data payload".  When I put
 *  SSH_MAX_PAYLOAD_LEN in here, I would relatively routinely get
 *  crashes in which the remote end overran my specified maximum size
 *  by 9 bytes (ie, the difference between the size of a CHANNEL_DATA
 *  packet and the size of its data payload).  While I still think my
 *  reading is right, the wording is now frozen (and thus won't change
 *  even if it turns out I'm right) and other implementations aren't
 *  going to change their deployed base overnight even if they agree
 *  with me today.  So we allow some slop.  It's tempting to produce
 *  nag messages if we detect a peer treating this value as a max data
 *  _payload_ size instead of a max data _packet_ size, in an attempt
 *  to get people to fix their other implementations, but for now I'm
 *  holding off on that; I'm going to try to get this nailed down on
 *  the WG list first.
 *
 * We take the opposite interpretation when handling maxsend values
 *  from incoming CHANNEL_OPEN and CHANNEL_OPEN_CONFIRMATION messages,
 *  taking them as maximum data packet size rather than maximum data
 *  payload size.  This is not because we're twisted (though that might
 *  be a defensible position :), but because we're conservative; doing
 *  this causes us to use a lower value, making it harder to overrun
 *  other implementations.  (Besides, it's what the spec specifies. :)
 *  (Actually, we do this only if the max-packet value is >13;
 *  otherwise, when we subtract 13, the result would be zero or
 *  negative.  Anyone specifying a value that small *must* be treating
 *  it as a max payload size rather than a max total packet size - or
 *  severely buggy, I suppose.)
 *
 * 13 is the difference between a CHANNEL_EXTENDED_DATA packet size and
 *  its data payload size.  This is the largest overhead we have to
 *  deal with; for CHANNEL_DATA packets, the overhead is only 9, but
 *  there's only one value, so we have to deduct for the largest packet
 *  overhead.
 */
#define MAX_PACKET_SIZE_VALUE (SSH_MAX_PAYLOAD_LEN-13)

#endif