2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
2011-06-06 10:43:46 +00:00
|
|
|
|
2007-08-19 17:18:33 -07:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-12-27 02:43:12 -02:00
|
|
|
|
2005-08-09 20:45:21 -07:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
2012-10-13 10:46:48 +01:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
2007-11-28 11:34:53 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-22 10:22:24 -07:00
|
|
|
|
2007-11-28 11:34:53 -02:00
|
|
|
|
|
|
|
|
|
2007-11-20 21:56:37 -02:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-11-28 11:34:53 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-22 10:22:24 -07:00
|
|
|
|
2007-11-28 11:34:53 -02:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
2006-11-10 11:22:32 -02:00
|
|
|
|
|
|
|
|
|
2007-03-13 13:06:52 -03:00
|
|
|
|
|
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
2006-11-10 11:22:32 -02:00
|
|
|
|
|
|
|
|
|
2007-10-24 10:12:09 -02:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
2007-10-24 10:12:09 -02:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:55 -07:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
2007-10-24 10:12:09 -02:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
2006-03-20 19:23:32 -08:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
2007-10-24 10:12:09 -02:00
|
|
|
|
2006-03-20 19:23:32 -08:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 19:23:32 -08:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-25 18:04:18 -07:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:26:55 -07:00
|
|
|
|
2005-08-09 20:26:03 -07:00
|
|
|
|
|
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-26 18:22:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
2008-11-04 23:55:49 -08:00
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-26 18:22:02 -07:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2012-02-26 18:22:02 -07:00
|
|
|
|
2006-03-20 19:23:32 -08:00
|
|
|
|
2008-11-04 23:55:49 -08:00
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:45:21 -07:00
|
|
|
|
|
|
|
|
|
2007-12-13 12:29:24 -02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2008-07-13 11:51:40 +01:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-09-16 16:58:40 -07:00
|
|
|
|
|
|
|
|
|
2006-03-20 19:23:32 -08:00
|
|
|
|
2005-09-16 16:58:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-10 16:01:18 -02:00
|
|
|
|
2005-09-16 16:58:40 -07:00
|
|
|
|
2015-10-08 21:28:58 +08:00
|
|
|
|
2006-03-20 19:23:32 -08:00
|
|
|
|
2005-09-16 16:58:40 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-10-08 21:28:58 +08:00
|
|
|
|
2005-09-16 16:58:40 -07:00
|
|
|
|
2015-10-08 21:28:58 +08:00
|
|
|
|
2005-09-16 16:58:40 -07:00
|
|
|
|
|
|
|
|
|
2005-09-18 00:17:51 -07:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-11-14 12:57:34 -02:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
2007-04-20 13:57:21 -07:00
|
|
|
|
|
|
|
|
|
2009-01-16 23:36:31 +00:00
|
|
|
|
|
|
|
|
|
2006-11-10 17:43:06 -02:00
|
|
|
|
|
|
|
|
|
2008-12-08 01:18:37 -08:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2007-04-20 13:57:21 -07:00
|
|
|
|
2007-09-26 11:31:49 -03:00
|
|
|
|
2008-11-04 23:55:49 -08:00
|
|
|
|
2005-09-18 00:17:51 -07:00
|
|
|
|
2007-04-20 13:57:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-04 13:38:01 +01:00
|
|
|
|
|
|
|
|
|
2007-04-20 13:57:21 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-13 12:25:01 -02:00
|
|
|
|
2010-11-14 17:25:46 +01:00
|
|
|
|
dccp: Extend CCID packet dequeueing interface
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27 19:16:26 +00:00
|
|
|
|
|
|
|
|
|
2007-03-20 15:27:17 -03:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-20 15:27:17 -03:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-03-20 19:23:32 -08:00
|
|
|
|
2008-02-03 04:07:48 -08:00
|
|
|
|
2005-09-16 16:58:40 -07:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
[DCCP]: Handle timestamps on Request/Response exchange separately
In DCCP, timestamps can occur on packets anytime, CCID3 uses a timestamp(/echo) on the Request/Response
exchange. This patch addresses the following situation:
* timestamps are recorded on the listening socket;
* Responses are sent from dccp_request_sockets;
* suppose two connections reach the listening socket with very small time in between:
* the first timestamp value gets overwritten by the second connection request.
This is not really good, so this patch separates timestamps into
* those which are received by the server during the initial handshake (on dccp_request_sock);
* those which are received by the client or the client after connection establishment.
As before, a timestamp of 0 is regarded as indicating that no (meaningful) timestamp has been
received (in addition, a warning message is printed if hosts send 0-valued timestamps).
The timestamp-echoing now works as follows:
* when a timestamp is present on the initial Request, it is placed into dreq, due to the
call to dccp_parse_options in dccp_v{4,6}_conn_request;
* when a timestamp is present on the Ack leading from RESPOND => OPEN, it is copied over
from the request_sock into the child cocket in dccp_create_openreq_child;
* timestamps received on an (established) dccp_sock are treated as before.
Since Elapsed Time is measured in hundredths of milliseconds (13.2), the new dccp_timestamp()
function is used, as it is expected that the time between receiving the timestamp and
sending the timestamp echo will be very small against the wrap-around time. As a byproduct,
this allows smaller timestamping-time fields.
Furthermore, inserting the Timestamp Echo option has been taken out of the block starting with
'!dccp_packet_without_ack()', since Timestamp Echo can be carried on any packet (5.8 and 13.3).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-12-13 12:37:19 -02:00
|
|
|
|
2006-03-20 17:41:47 -08:00
|
|
|
|
|
|
|
|
|
2009-01-16 23:36:31 +00:00
|
|
|
|
|
|
|
|
|
2008-11-16 22:53:48 -08:00
|
|
|
|
|
|
|
|
|
2008-12-08 01:18:37 -08:00
|
|
|
|
2008-07-13 11:51:40 +01:00
|
|
|
|
2007-09-26 11:31:49 -03:00
|
|
|
|
2008-11-04 23:55:49 -08:00
|
|
|
|
2005-09-18 00:17:51 -07:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-04 13:38:01 +01:00
|
|
|
|
|
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2005-09-09 02:30:07 -03:00
|
|
|
|
|
|
|
|
|
2007-12-13 12:25:01 -02:00
|
|
|
|
2010-11-14 17:25:46 +01:00
|
|
|
|
dccp: Extend CCID packet dequeueing interface
This extends the packet dequeuing interface of dccp_write_xmit() to allow
1. CCIDs to take care of timing when the next packet may be sent;
2. delayed sending (as before, with an inter-packet gap up to 65.535 seconds).
The main purpose is to take CCID-2 out of its polling mode (when it is network-
limited, it tries every millisecond to send, without interruption).
The mode of operation for (2) is as follows:
* new packet is enqueued via dccp_sendmsg() => dccp_write_xmit(),
* ccid_hc_tx_send_packet() detects that it may not send (e.g. window full),
* it signals this condition via `CCID_PACKET_WILL_DEQUEUE_LATER',
* dccp_write_xmit() returns without further action;
* after some time the wait-condition for CCID becomes true,
* that CCID schedules the tasklet,
* tasklet function calls ccid_hc_tx_send_packet() via dccp_write_xmit(),
* since the wait-condition is now true, ccid_hc_tx_packet() returns "send now",
* packet is sent, and possibly more (since dccp_write_xmit() loops).
Code reuse: the taskled function calls dccp_write_xmit(), the timer function
reduces to a wrapper around the same code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27 19:16:26 +00:00
|
|
|
|
2006-08-26 19:16:45 -07:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
2006-12-10 16:01:18 -02:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-22 10:22:19 -07:00
|
|
|
|
2012-04-12 22:16:05 +00:00
|
|
|
|
2005-08-09 20:14:34 -07:00
|
|
|
|
