[drats_users] D-RATS 0.3.2b1

[Dan Smith]

Hi all,

I just posted 0.3.2b1.  This beta includes some changes to the file
transfer logic, which is potentially destabilizing, so I'd appreciate
some testing from folks.  The changes are:

- Fix station type QST
- Make the message router aware of the last heard time of a station and
  ping the station if it has been a while instead of just blindly
  initiating a transfer
- Fix continuously adding "RE:" to replied message subjects
- Add a preference option to control whether or not the original message
  is included on a reply
- Add gratuitous message routing with reverse path on reply
- Add some brains to the message router to prevent it from sending email
  messages to itself in a loop and to better determine which of those
  received via email should be sent out to another station
- Add a Send/Receive button to the toolbar which lets you trigger the
  automatic message router once, without having to have it always
  enabled
- Add some tooltips to the messages tab to explain things like
  "Send/Receive" and "Forward"
- Major cleanup of the session code, removing the legacy "non-pipelined"
  transport code
- Make the transport layer measure some stats about the connection speed
  and latency and use those to better choose ACK timeout values
- Cut down some of the delays involved in the initial handshake between
  stations when starting a session
- Allow the transfer logic to grow/shrink its window size according to
  the conditions of the transfer.

Some notes about these changes:

- Gratuitous message routing allows you to put something like
  "N7QQU,N7OGM,KK7DS" in the destination field of a message.  If each
  station along the way has message forwarding enabled, then they will
  obey that route and the message will pass from the sender to N7QQU,
  then to N7OGM, and then to KK7DS.  This allows you to specify the best
  route for the message to take, if that is advantageous.  A reply to a
  message routed in this manner will reverse the route so that the reply
  goes back along the same path automatically.

- The "last heard" logic should help make automatic forwarding a little
  more bandwidth-conscious in that it will make sure it can ping a
  station it hasn't heard in a while before trying to transfer a message
  to it.

- The transfer logic has been changed in such a way that it *should*
  make better decisions about ACK timeouts when messages pass through
  multiple networks of varying latency.  If you're seeing suboptimal
  behavior through a repeater or proxy, this should help.

- The transfer logic also now tries to improve performance when the
  connection is good by scaling up the amount of data that is sent each
  time.  The "pipeline blocks" setting is still the default.  However,
  each time the remote station reports that it got every block that we
  sent, we increase the window by one.  If we sent four blocks that
  time, then next time we send five.  If those are received, then we
  send six the next time, and so on.  Any time we miss a block, we drop
  back to the default and re-evaluate.  If we miss a block from the
  default, we start reducing the window size by one until we get to a
  minimum.  This change should help automatically accelerate long
  transfers when the connection is good.

Feedback on any or all of this would be appreciated.

Thanks!

-- 
Dan Smith
dsmith#danplanet.com, s/#/@/
www.danplanet.com
KK7DS