2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 13:51:31 +08:00
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-01-11 13:30:43 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-01-11 13:30:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-01-11 13:30:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-04 11:54:43 -04:00
|
|
|
|
|
|
|
|
|
2008-09-02 23:38:32 -07:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-27 12:54:39 +08:00
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2011-02-25 19:11:25 -05:00
|
|
|
|
2011-11-04 11:54:43 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-23 04:49:13 +00:00
|
|
|
|
2011-11-04 11:54:43 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-27 15:03:24 -04:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-17 18:02:01 -04:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
|
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
|
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-02 23:38:32 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2008-05-21 14:53:00 -07:00
|
|
|
|
2010-12-31 18:59:23 +00:00
|
|
|
|
2006-06-25 23:52:17 -07:00
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
2006-06-25 23:52:17 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:18 +00:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
|
|
|
|
|
2006-06-25 23:52:17 -07:00
|
|
|
|
2010-12-31 18:59:19 +00:00
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
2014-05-08 08:54:39 +08:00
|
|
|
|
2011-10-28 16:26:41 -04:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
|
|
|
|
|
2006-06-25 23:52:17 -07:00
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-31 18:59:19 +00:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2011-12-29 20:58:42 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-12-29 20:58:42 -05:00
|
|
|
|
2014-04-24 16:26:46 +02:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-06-25 23:52:50 -07:00
|
|
|
|
2014-04-24 16:26:46 +02:00
|
|
|
|
|
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
tipc: decouple the relationship between bearer and link
Currently on both paths of message transmission and reception, the
read lock of tipc_net_lock must be held before bearer is accessed,
while the write lock of tipc_net_lock has to be taken before bearer
is configured. Although it can ensure that bearer is always valid on
the two data paths, link and bearer is closely bound together.
So as the part of effort of removing tipc_net_lock, the locking
policy of bearer protection will be adjusted as below: on the two
data paths, RCU is used, and on the configuration path of bearer,
RTNL lock is applied.
Now RCU just covers the path of message reception. To make it possible
to protect the path of message transmission with RCU, link should not
use its stored bearer pointer to access bearer, but it should use the
bearer identity of its attached bearer as index to get bearer instance
from bearer_list array, which can help us decouple the relationship
between bearer and link. As a result, bearer on the path of message
transmission can be safely protected by RCU when we access bearer_list
array within RCU lock protection.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 10:55:46 +08:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-02-18 16:06:46 +08:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
2006-06-25 23:52:17 -07:00
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-02 23:38:32 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-12-29 20:58:42 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2011-12-29 20:58:42 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-12-29 20:58:42 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-12-29 20:58:42 -05:00
|
|
|
|
2014-04-24 16:26:46 +02:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-06-25 23:52:50 -07:00
|
|
|
|
2014-04-24 16:26:46 +02:00
|
|
|
|
2006-06-25 23:52:50 -07:00
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
tipc: decouple the relationship between bearer and link
Currently on both paths of message transmission and reception, the
read lock of tipc_net_lock must be held before bearer is accessed,
while the write lock of tipc_net_lock has to be taken before bearer
is configured. Although it can ensure that bearer is always valid on
the two data paths, link and bearer is closely bound together.
So as the part of effort of removing tipc_net_lock, the locking
policy of bearer protection will be adjusted as below: on the two
data paths, RCU is used, and on the configuration path of bearer,
RTNL lock is applied.
Now RCU just covers the path of message reception. To make it possible
to protect the path of message transmission with RCU, link should not
use its stored bearer pointer to access bearer, but it should use the
bearer identity of its attached bearer as index to get bearer instance
from bearer_list array, which can help us decouple the relationship
between bearer and link. As a result, bearer on the path of message
transmission can be safely protected by RCU when we access bearer_list
array within RCU lock protection.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 10:55:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
tipc: decouple the relationship between bearer and link
Currently on both paths of message transmission and reception, the
read lock of tipc_net_lock must be held before bearer is accessed,
while the write lock of tipc_net_lock has to be taken before bearer
is configured. Although it can ensure that bearer is always valid on
the two data paths, link and bearer is closely bound together.
So as the part of effort of removing tipc_net_lock, the locking
policy of bearer protection will be adjusted as below: on the two
data paths, RCU is used, and on the configuration path of bearer,
RTNL lock is applied.
Now RCU just covers the path of message reception. To make it possible
to protect the path of message transmission with RCU, link should not
use its stored bearer pointer to access bearer, but it should use the
bearer identity of its attached bearer as index to get bearer instance
from bearer_list array, which can help us decouple the relationship
between bearer and link. As a result, bearer on the path of message
transmission can be safely protected by RCU when we access bearer_list
array within RCU lock protection.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 10:55:46 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2014-01-07 17:02:41 -05:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-28 11:36:21 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2010-08-17 11:00:12 +00:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-09-02 23:38:32 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-02-28 11:36:21 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2011-12-29 20:58:42 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
tipc: decouple the relationship between bearer and link
Currently on both paths of message transmission and reception, the
read lock of tipc_net_lock must be held before bearer is accessed,
while the write lock of tipc_net_lock has to be taken before bearer
is configured. Although it can ensure that bearer is always valid on
the two data paths, link and bearer is closely bound together.
So as the part of effort of removing tipc_net_lock, the locking
policy of bearer protection will be adjusted as below: on the two
data paths, RCU is used, and on the configuration path of bearer,
RTNL lock is applied.
Now RCU just covers the path of message reception. To make it possible
to protect the path of message transmission with RCU, link should not
use its stored bearer pointer to access bearer, but it should use the
bearer identity of its attached bearer as index to get bearer instance
from bearer_list array, which can help us decouple the relationship
between bearer and link. As a result, bearer on the path of message
transmission can be safely protected by RCU when we access bearer_list
array within RCU lock protection.
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Erik Hugne <erik.hugne@ericsson.com>
Tested-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-21 10:55:46 +08:00
|
|
|
|
2014-03-27 12:54:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-28 11:32:27 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2011-12-29 20:58:42 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
tipc: delay delete of link when failover is needed
When a bearer is disabled, all its attached links are deleted.
Ideally, we should do link failover to redundant links on other bearers,
if there are any, in such cases. This would be consistent with current
behavior when a link is reset, but not deleted. However, due to the
complexity involved, and the (wrongly) perceived low demand for this
feature, it was never implemented until now.
We mark the doomed link for deletion with a new flag, but wait until the
failover process is finished before we actually delete it. With the
improved link tunnelling/failover code introduced earlier in this commit
series, it is now easy to identify a spot in the code where the failover
is finished and it is safe to delete the marked link. Moreover, the test
for the flag and the deletion can be done synchronously, and outside the
most time critical data path.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-13 17:29:16 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-14 16:40:43 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-27 12:54:39 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-14 16:40:43 -05:00
|
|
|
|
tipc: delay delete of link when failover is needed
When a bearer is disabled, all its attached links are deleted.
Ideally, we should do link failover to redundant links on other bearers,
if there are any, in such cases. This would be consistent with current
behavior when a link is reset, but not deleted. However, due to the
complexity involved, and the (wrongly) perceived low demand for this
feature, it was never implemented until now.
We mark the doomed link for deletion with a new flag, but wait until the
failover process is finished before we actually delete it. With the
improved link tunnelling/failover code introduced earlier in this commit
series, it is now easy to identify a spot in the code where the failover
is finished and it is safe to delete the marked link. Moreover, the test
for the flag and the deletion can be done synchronously, and outside the
most time critical data path.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-13 17:29:16 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-09-02 23:38:32 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-05-08 08:54:39 +08:00
|
|
|
|
tipc: introduce message to synchronize broadcast link
Upon establishing a first link between two nodes, there is
currently a risk that the two endpoints will disagree on exactly
which sequence number reception and acknowleding of broadcast
packets should start.
The following scenarios may happen:
1: Node A sends an ACTIVATE message to B, telling it to start acking
packets from sequence number N.
2: Node A sends out broadcast N, but does not expect an acknowledge
from B, since B is not yet in its broadcast receiver's list.
3: Node A receives ACK for N from all nodes except B, and releases
packet N.
4: Node B receives the ACTIVATE, activates its link endpoint, and
stores the value N as sequence number of first expected packet.
5: Node B sends a NAME_DISTR message to A.
6: Node A receives the NAME_DISTR message, and activates its endpoint.
At this moment B is added to A's broadcast receiver's set.
Node A also sets sequence number 0 as the first broadcast packet
to be received from B.
7: Node A sends broadcast N+1.
8: B receives N+1, determines there is a gap in the sequence, since
it is expecting N, and sends a NACK for N back to A.
9: Node A has already released N, so no retransmission is possible.
The broadcast link in direction A->B is stale.
In addition to, or instead of, 7-9 above, the following may happen:
10: Node B sends broadcast M > 0 to A.
11: Node A receives M, falsely decides there must be a gap, since
it is expecting packet 0, and asks for retransmission of packets
[0,M-1].
12: Node B has already released these packets, so the broadcast
link is stale in direction B->A.
We solve this problem by introducing a new unicast message type,
BCAST_PROTOCOL/STATE, to convey the sequence number of the next
sent broadcast packet to the other endpoint, at exactly the moment
that endpoint is added to the own node's broadcast receivers list,
and before any other unicast messages are permitted to be sent.
Furthermore, we don't allow any node to start receiving and
processing broadcast packets until this new synchronization
message has been received.
To maintain backwards compatibility, we still open up for
broadcast reception if we receive a NAME_DISTR message without
any preceding broadcast sync message. In this case, we must
assume that the other end has an older code version, and will
never send out the new synchronization message. Hence, for mixed
old and new nodes, the issue arising in 7-12 of the above may
happen with the same probability as before.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2012-11-16 13:51:31 +08:00
|
|
|
|
2012-11-16 13:51:29 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-09-02 23:38:32 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-29 00:16:37 -04:00
|
|
|
|
|
|
|
|
|
2011-04-07 11:58:08 -04:00
|
|
|
|
|
|
|
|
|
2012-11-16 13:51:30 +08:00
|
|
|
|
2013-12-10 20:45:38 -08:00
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-27 14:17:53 -04:00
|
|
|
|
2011-04-07 11:58:08 -04:00
|
|
|
|
2014-05-14 05:39:12 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-07 11:58:08 -04:00
|
|
|
|
|
|
|
|
|
2011-10-24 11:18:12 -04:00
|
|
|
|
2011-10-24 15:26:24 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2012-11-16 13:51:30 +08:00
|
|
|
|
2011-04-07 11:58:08 -04:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-29 20:58:42 -05:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-05-08 08:54:40 +08:00
|
|
|
|
|
|
|
|
|
2014-05-05 08:56:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-08 08:54:40 +08:00
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-02 23:38:32 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-06-29 12:33:20 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-11-08 00:19:09 -08:00
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2008-07-14 22:44:58 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2010-12-31 18:59:17 +00:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
2008-07-14 22:44:58 -07:00
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2006-06-29 12:33:20 -07:00
|
|
|
|
|
|
|
|
|
2008-07-14 22:44:58 -07:00
|
|
|
|
2014-03-27 12:54:38 +08:00
|
|
|
|
|
|
|
|
|
2006-06-29 12:33:20 -07:00
|
|
|
|
2014-03-27 12:54:38 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
|
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-02 23:38:32 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-06-29 12:33:20 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2006-11-08 00:19:09 -08:00
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-11-08 13:48:28 -05:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
tipc: Major redesign of broadcast link ACK/NACK algorithms
Completely redesigns broadcast link ACK and NACK mechanisms to prevent
spurious retransmit requests in dual LAN networks, and to prevent the
broadcast link from stalling due to the failure of a receiving node to
acknowledge receiving a broadcast message or request its retransmission.
Note: These changes only impact the timing of when ACK and NACK messages
are sent, and not the basic broadcast link protocol itself, so inter-
operability with nodes using the "classic" algorithms is maintained.
The revised algorithms are as follows:
1) An explicit ACK message is still sent after receiving 16 in-sequence
messages, and implicit ACK information continues to be carried in other
unicast link message headers (including link state messages). However,
the timing of explicit ACKs is now based on the receiving node's absolute
network address rather than its relative network address to ensure that
the failure of another node does not delay the ACK beyond its 16 message
target.
2) A NACK message is now typically sent only when a message gap persists
for two consecutive incoming link state messages; this ensures that a
suspected gap is not confirmed until both LANs in a dual LAN network have
had an opportunity to deliver the message, thereby preventing spurious NACKs.
A NACK message can also be generated by the arrival of a single link state
message, if the deferred queue is so big that the current message gap
cannot be the result of "normal" mis-ordering due to the use of dual LANs
(or one LAN using a bonded interface). Since link state messages typically
arrive at different nodes at different times the problem of multiple nodes
issuing identical NACKs simultaneously is inherently avoided.
3) Nodes continue to "peek" at NACK messages sent by other nodes. If
another node requests retransmission of a message gap suspected (but not
yet confirmed) by the peeking node, the peeking node forgets about the
gap and does not generate a duplicate retransmit request. (If the peeking
node subsequently fails to receive the lost message, later link state
messages will cause it to rediscover and confirm the gap and send another
NACK.)
4) Message gap "equality" is now determined by the start of the gap only.
This is sufficient to deal with the most common cases of message loss,
and eliminates the need for complex end of gap computations.
5) A peeking node no longer tries to determine whether it should send a
complementary NACK, since the most common cases of message loss don't
require it to be sent. Consequently, the node no longer examines the
"broadcast tag" field of a NACK message when peeking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2011-10-27 14:17:53 -04:00
|
|
|
|
2014-03-27 12:54:39 +08:00
|
|
|
|
2008-07-14 22:44:58 -07:00
|
|
|
|
2014-03-27 12:54:36 +08:00
|
|
|
|
2006-06-29 12:33:20 -07:00
|
|
|
|
|
|
|
|
|
2008-07-14 22:44:58 -07:00
|
|
|
|
2014-03-27 12:54:39 +08:00
|
|
|
|
|
|
|
|
|
2006-06-29 12:33:20 -07:00
|
|
|
|
2014-03-27 12:54:39 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-23 11:44:49 -05:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2009-03-18 19:11:29 -07:00
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
|
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2011-02-25 18:42:52 -05:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2008-07-14 22:44:58 -07:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-01-18 00:38:21 +01:00
|
|
|
|
2007-02-09 23:25:21 +09:00
|
|
|
|
2008-07-14 22:44:58 -07:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
2014-03-27 12:54:37 +08:00
|
|
|
|
2006-01-02 19:04:38 +01:00
|
|
|
|
|
|
|
|
|
2014-04-24 16:26:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-04-28 08:20:09 +02:00
|
|
|
|
2014-04-24 16:26:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 08:56:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 08:56:14 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 08:56:12 +08:00
|
|
|
|
2014-05-08 08:54:39 +08:00
|
|
|
|
2014-05-05 08:56:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-08 08:54:39 +08:00
|
|
|
|
2014-05-05 08:56:12 +08:00
|
|
|
|
2014-05-08 08:54:39 +08:00
|
|
|
|
2014-05-05 08:56:12 +08:00
|
|
|
|
2014-05-08 08:54:39 +08:00
|
|
|
|
2014-05-05 08:56:14 +08:00
|
|
|
|
2014-05-08 08:54:39 +08:00
|
|
|
|
2014-05-05 08:56:14 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 08:56:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-05 08:56:14 +08:00
|
|
|
|
|
|
|
|
|
2014-05-05 08:56:12 +08:00
|
|
|
|