System.err.println ("Adaptive setRTT="+rtt+" for "+MessageUtils.toString(msg));
  private DestinationLink linkChoice (DestinationLink link, AttributedMessage msg)  {    if (debug) log.debug ("Link choice: " +(link != null? getName(link) : "null")+                           " for " +MessageUtils.toString(msg));    if (link != null)    {      recordLinkSelection (link, msg);      MessageUtils.setSendProtocolLink (msg, getName(link));      //  For resends (new messages don't have acks yet) update the ack with      //  the new link selection as soon as possible so that the resender      //  can know the correct resend timeout for the newly chosen link.        //  Before this occurs, the resender is working with the timeout      //  from the last link used - and if the process of getting a new      //  link takes long enough will resend based on that timeout.  This      //  should be a rare event though, because the time to choose a new      //  link should generally always be much less than the average full      //  RTT of any link.  Note retrys also use this info, but there the      //  message resender is not involved.      Ack ack = MessageUtils.getAck (msg);      if (ack != null)      {        ack.setSendLink (getName (link));        String targetNode = MessageUtils.getToAgentNode (msg);        int rtt = rttService.getBestFullRTTForLink (link, targetNode);System.err.println ("service rtt="+rtt);        if (rtt <= 0) rtt = link.cost (msg);System.err.println ("Adaptive setRTT="+rtt+" for "+MessageUtils.toString(msg));        ack.setRTT (rtt);        MessageAckingAspect.dingTheMessageResender();  // calc new deadlines      }      if (showTraffic) showProgress (link);    }    return link;  }