An error occurred fetching the project authors.
  1. 11 Feb, 2007 1 commit
  2. 11 Dec, 2006 1 commit
  3. 03 Dec, 2006 3 commits
    • Gerrit Renker's avatar
      [DCCP]: Remove forward declarations in timer.c · 4ed800d0
      Gerrit Renker authored
      This removes 3 forward declarations by reordering 2 functions.
      
      No code change at all.
      Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@mandriva.com>
      4ed800d0
    • Gerrit Renker's avatar
      [DCCP]: Add sysctls to control retransmission behaviour · 2e2e9e92
      Gerrit Renker authored
      This adds 3 sysctls which govern the retransmission behaviour of DCCP control
      packets (3way handshake, feature negotiation).
      
      It removes 4 FIXMEs from the code.
      
      The close resemblance of sysctl variables to their TCP analogues is emphasised
      not only by their name, but also by giving them the same initial values.
      This is useful since there is not much practical experience with DCCP yet.
      
      Furthermore, with regard to the previous patch, it is now possible to limit
      the number of keepalive-Responses by setting net.dccp.default.request_retries
      (also a bit like in TCP).
      
      Lastly, added documentation of all existing DCCP sysctls.
      Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@mandriva.com>
      2e2e9e92
    • Gerrit Renker's avatar
      [DCCP]: Update comments on precisely which packets can be retransmitted · 08a29e41
      Gerrit Renker authored
      This updates program documentation: spell out precise conditions about
      which packets are eligible for retransmission (which is actually quite
      hard to extract from RFC 4340).
      
      It is based on the following table derived from RFC 4340:
      
      +-----------+---------------------------------+---------------------+
      |   Type    | Retransmit?                     |  Remark             |
      +-----------+---------------------------------+---------------------+
      | Request   |  in client-REQUEST state        | sec. 8.1.1          |
      | Response  |  NEVER                          | SHOULD NOT, 8.1.3   |
      | Data      |  NEVER                          | unreliable protocol |
      | Ack       |  possible in client-PARTOPEN    | sec. 8.1.5          |
      | DataAck   |  NEVER                          | unreliable protocol |
      | CloseReq  |  only in server-CLOSEREQ state  | MUST, sec. 8.3      |
      | Close     |  in node-CLOSING state          | MUST, sec. 8.3      |
      +-----------+-------------------------------------------------------+
      | Reset     |  only in response to other packets                    |
      | Sync      |  only in response to sequence-invalid packets (7.5.4) |
      | SyncAck   |  only in response to Sync packets                     |
      +-----------+-------------------------------------------------------+
      
      Hence the only packets eligible for retransmission are:
             * Requests in client-REQUEST  state (sec. 8.1.1)
             * Acks     in client-PARTOPEN state (sec. 8.1.5)
             * CloseReq in server-CLOSEREQ state (sec. 8.3)
             * Close    in   node-CLOSING  state (sec. 8.3)
      
      I had meant to put in a check for these types too, but have left that
      for later.
      Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@mandriva.com>
      08a29e41
  4. 30 Jun, 2006 1 commit
  5. 21 Mar, 2006 2 commits
  6. 29 Aug, 2005 4 commits