)]}'
{
  "commit": "b1fcf55eea541af9efa5d39f5a0d1aec8ceca55d",
  "tree": "a021b6abde9c784d67ee0de3bb7fb31f7d5b2e9f",
  "parents": [
    "dc841e30eaea9f9f83c9ab1ee0b3ef9e5c95ce8a"
  ],
  "author": {
    "name": "Gerrit Renker",
    "email": "gerrit@erg.abdn.ac.uk",
    "time": "Wed Oct 27 19:16:27 2010 +0000"
  },
  "committer": {
    "name": "David S. Miller",
    "email": "davem@davemloft.net",
    "time": "Thu Oct 28 10:27:01 2010 -0700"
  },
  "message": "dccp: Refine the wait-for-ccid mechanism\n\nThis extends the existing wait-for-ccid routine so that it may be used with\ndifferent types of CCID, addressing the following problems:\n\n 1) The queue-drain mechanism only works with rate-based CCIDs. If CCID-2 for\n    example has a full TX queue and becomes network-limited just as the\n    application wants to close, then waiting for CCID-2 to become unblocked\n    could lead to an indefinite  delay (i.e., application \"hangs\").\n 2) Since each TX CCID in turn uses a feedback mechanism, there may be changes\n    in its sending policy while the queue is being drained. This can lead to\n    further delays during which the application will not be able to terminate.\n 3) The minimum wait time for CCID-3/4 can be expected to be the queue length\n    times the current inter-packet delay. For example if tx_qlen\u003d100 and a delay\n    of 15 ms is used for each packet, then the application would have to wait\n    for a minimum of 1.5 seconds before being allowed to exit.\n 4) There is no way for the user/application to control this behaviour. It would\n    be good to use the timeout argument of dccp_close() as an upper bound. Then\n    the maximum time that an application is willing to wait for its CCIDs to can\n    be set via the SO_LINGER option.\n\nThese problems are addressed by giving the CCID a grace period of up to the\n`timeout\u0027 value.\n\nThe wait-for-ccid function is, as before, used when the application\n (a) has read all the data in its receive buffer and\n (b) if SO_LINGER was set with a non-zero linger time, or\n (c) the socket is either in the OPEN (active close) or in the PASSIVE_CLOSEREQ\n     state (client application closes after receiving CloseReq).\n\nIn addition, there is a catch-all case of __skb_queue_purge() after waiting for\nthe CCID. This is necessary since the write queue may still have data when\n (a) the host has been passively-closed,\n (b) abnormal termination (unread data, zero linger time),\n (c) wait-for-ccid could not finish within the given time limit.\n\nSigned-off-by: Gerrit Renker \u003cgerrit@erg.abdn.ac.uk\u003e\nSigned-off-by: David S. Miller \u003cdavem@davemloft.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "3eb264b608239c74c16d27625cc4b3b5199a3ef8",
      "old_mode": 33188,
      "old_path": "net/dccp/dccp.h",
      "new_id": "a8ed459508b294feb774c1597e788fa38313e995",
      "new_mode": 33188,
      "new_path": "net/dccp/dccp.h"
    },
    {
      "type": "modify",
      "old_id": "11418a9a389d3564654d3b5a971dafe481f14969",
      "old_mode": 33188,
      "old_path": "net/dccp/output.c",
      "new_id": "45b91853f5aee3d452d5795da832b9e1f04651ed",
      "new_mode": 33188,
      "new_path": "net/dccp/output.c"
    },
    {
      "type": "modify",
      "old_id": "7e5fc04eb6d1989986b7c7241f0e5cb2106ce4d8",
      "old_mode": 33188,
      "old_path": "net/dccp/proto.c",
      "new_id": "ef343d53fcea22edf7d7bb2be677f349ec63f547",
      "new_mode": 33188,
      "new_path": "net/dccp/proto.c"
    },
    {
      "type": "modify",
      "old_id": "916f9d1dab36e2f3616a9c6bea95b3fb37092671",
      "old_mode": 33188,
      "old_path": "net/dccp/timer.c",
      "new_id": "7587870b7040d0d997a54efd4d2c0786a1bb8a7d",
      "new_mode": 33188,
      "new_path": "net/dccp/timer.c"
    }
  ]
}