From mouse  Sat Sep 23 03:33:08 2006
Return-Path: <mouse>
Received: (from mouse@localhost)
	by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id DAA05703;
	Sat, 23 Sep 2006 03:33:08 -0400 (EDT)
From: der Mouse <mouse>
Message-Id: <200609230733.DAA05703@Sparkle.Rodents.Montreal.QC.CA>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
Date: Sat, 23 Sep 2006 03:20:25 -0400 (EDT)
To: mouseware
Subject: new moussh, moussh-20060923

New in this version:

- "Fix" for the 35009-byte packet problem.  The problem here is that
   the spec defines a field in channel open messages that is the
   "maximum packet size", documented as "the maximum size of an
   individual data packet that can be sent to the sender [of the
   message containing the value]".  However, existing implementations
   treat it not as the maximum data packet size, but rather as the
   maximum data payload size in a CHANNEL_DATA or CHANNEL_EXTENDED_DATA
   message, which is a difference of 9 or 13.  So if we actually put
   the maximum data packet size we can accept there, other
   implementions will routinely overflow it by 9 (regular data) or 13
   (extended data, used for stderr).  As tempting as it is to write
   this off as their being broken, I can't quite justify that, since
   the sense of the WG is that their interpretation is the correct one,
   despite the wording clearly pointing the other way.  (And even if I
   did want to be that stringent, I'd still want to make it work in
   some sense for interoperability's sake.)  Before this change, I
   would occasionally get crashes when connecting to other
   implementations when they overran my 35000-byte max payload length,
   usually by 9 bytes (hence "the 35009-byte packet problem").

- Fix for breaking up large output data.  This matters only when
   talking with an implementation with a very small max data payload
   size, since we never send more than about 8K in a single message,
   but it's necessary for correctness.  I really ought to add an option
   to artificially reduce the advertised max data payload, to permit
   testing this.

- Make client command-line "quit" work in all cases.

- Add some more internals commenting.

- Remove a testing shellscript which I forgot to get rid of when I no
   longer needed it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B