Contiki: Les retransmissions CoAP ne sont pas rejetées
J'ai découvert que CoAP Server ne supprime pas les paquets même s'ils ont déjà été reçus.
Dans mon cas, l'ACK envoyé par le serveur a été perdu, le client CoAP a donc effectué une retransmission et il n'a pas été rejeté par le serveur.
Pour reproduire le problème, je filtre tous les paquets entrants provenant du serveur côté Client.
$ sudo ip6tables -A INPUT -j DROP -p udp -s 2001:470:1f12:8c8:2::2000
Ensuite, j'ai commencé à surveiller le trafic côté client
$ sudo tcpdump -xx port 51461 -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
18:35:45.101755 IP6 2001:470:1f12:8c8:2::1001.52842 > 2001:470:1f12:8c8:2::2000.51461: UDP, length 65
0x0000: 600f ed4c 0049 1140 2001 0470 1f12 08c8
0x0010: 0002 0000 0000 1001 2001 0470 1f12 08c8
0x0020: 0002 0000 0000 2000 ce6a c905 0049 39e9
0x0030: 4402 e707 62d2 022a b961 6374 7561 746f
0x0040: 7273 0672 656d 6f74 6511 32ff 7b22 636f
0x0050: 6465 223a 5b32 3433 2c34 395d 2c22 6269
0x0060: 7473 223a 3133 2c22 7469 6d65 7322 3a39
0x0070: 7d
18:35:45.611813 IP6 2001:470:1f12:8c8:2::2000.51461 > 2001:470:1f12:8c8:2::1001.52842: UDP, length 9
0x0000: 6000 0000 0011 113e 2001 0470 1f12 08c8
0x0010: 0002 0000 0000 2000 2001 0470 1f12 08c8
0x0020: 0002 0000 0000 1001 c905 ce6a 0011 2f76
0x0030: 6445 e707 62d2 022a c0
18:35:47.694559 IP6 2001:470:1f12:8c8:2::1001.52842 > 2001:470:1f12:8c8:2::2000.51461: UDP, length 65
0x0000: 600f ed4c 0049 1140 2001 0470 1f12 08c8
0x0010: 0002 0000 0000 1001 2001 0470 1f12 08c8
0x0020: 0002 0000 0000 2000 ce6a c905 0049 39e9
0x0030: 4402 e707 62d2 022a b961 6374 7561 746f
0x0040: 7273 0672 656d 6f74 6511 32ff 7b22 636f
0x0050: 6465 223a 5b32 3433 2c34 395d 2c22 6269
0x0060: 7473 223a 3133 2c22 7469 6d65 7322 3a39
0x0070: 7d
18:35:48.344231 IP6 2001:470:1f12:8c8:2::2000.51461 > 2001:470:1f12:8c8:2::1001.52842: UDP, length 9
0x0000: 6000 0000 0011 113e 2001 0470 1f12 08c8
0x0010: 0002 0000 0000 2000 2001 0470 1f12 08c8
0x0020: 0002 0000 0000 1001 c905 ce6a 0011 2f76
0x0030: 6445 e707 62d2 022a c0
18:35:52.880162 IP6 2001:470:1f12:8c8:2::1001.52842 > 2001:470:1f12:8c8:2::2000.51461: UDP, length 65
0x0000: 600f ed4c 0049 1140 2001 0470 1f12 08c8
0x0010: 0002 0000 0000 1001 2001 0470 1f12 08c8
0x0020: 0002 0000 0000 2000 ce6a c905 0049 39e9
0x0030: 4402 e707 62d2 022a b961 6374 7561 746f
0x0040: 7273 0672 656d 6f74 6511 32ff 7b22 636f
0x0050: 6465 223a 5b32 3433 2c34 395d 2c22 6269
0x0060: 7473 223a 3133 2c22 7469 6d65 7322 3a39
0x0070: 7d
18:35:53.473285 IP6 2001:470:1f12:8c8:2::2000.51461 > 2001:470:1f12:8c8:2::1001.52842: UDP, length 9
0x0000: 6000 0000 0011 113e 2001 0470 1f12 08c8
0x0010: 0002 0000 0000 2000 2001 0470 1f12 08c8
0x0020: 0002 0000 0000 1001 c905 ce6a 0011 2f76
0x0030: 6445 e707 62d2 022a c0
18:36:03.250058 IP6 2001:470:1f12:8c8:2::1001.52842 > 2001:470:1f12:8c8:2::2000.51461: UDP, length 65
0x0000: 600f ed4c 0049 1140 2001 0470 1f12 08c8
0x0010: 0002 0000 0000 1001 2001 0470 1f12 08c8
0x0020: 0002 0000 0000 2000 ce6a c905 0049 39e9
0x0030: 4402 e707 62d2 022a b961 6374 7561 746f
0x0040: 7273 0672 656d 6f74 6511 32ff 7b22 636f
0x0050: 6465 223a 5b32 3433 2c34 395d 2c22 6269
0x0060: 7473 223a 3133 2c22 7469 6d65 7322 3a39
0x0070: 7d
18:36:03.768217 IP6 2001:470:1f12:8c8:2::2000.51461 > 2001:470:1f12:8c8:2::1001.52842: UDP, length 9
0x0000: 6000 0000 0011 113e 2001 0470 1f12 08c8
0x0010: 0002 0000 0000 2000 2001 0470 1f12 08c8
0x0020: 0002 0000 0000 1001 c905 ce6a 0011 2f76
0x0030: 6445 e707 62d2 022a c0
18:36:23.989485 IP6 2001:470:1f12:8c8:2::1001.52842 > 2001:470:1f12:8c8:2::2000.51461: UDP, length 65
0x0000: 600f ed4c 0049 1140 2001 0470 1f12 08c8
0x0010: 0002 0000 0000 1001 2001 0470 1f12 08c8
0x0020: 0002 0000 0000 2000 ce6a c905 0049 39e9
0x0030: 4402 e707 62d2 022a b961 6374 7561 746f
0x0040: 7273 0672 656d 6f74 6511 32ff 7b22 636f
0x0050: 6465 223a 5b32 3433 2c34 395d 2c22 6269
0x0060: 7473 223a 3133 2c22 7469 6d65 7322 3a39
0x0070: 7d
18:36:24.523162 IP6 2001:470:1f12:8c8:2::2000.51461 > 2001:470:1f12:8c8:2::1001.52842: UDP, length 9
0x0000: 6000 0000 0011 113e 2001 0470 1f12 08c8
0x0010: 0002 0000 0000 2000 2001 0470 1f12 08c8
0x0020: 0002 0000 0000 1001 c905 ce6a 0011 2f76
0x0030: 6445 e707 62d2 022a c0
Chaque fois que le paquet était reçu par le serveur, il n'était pas rejeté et un ACK était renvoyé au client.
Merci.
alejandr0
Tous les 12 commentaires
Une mise à jour pour ceci? Toujours le même problème avec la dernière version de Contiki. @joakimeriksson pourriez-vous m'aider à ce sujet ?.
Merci d'avance.
alejandr0
le 15 févr. 2017
Nous vivons exactement le même problème. N'importe quelle aide sur ceci serait beaucoup appréciée !
dariushs20
le 8 mars 2017
alejandr0 as-tu eu une réponse ? ... nous avons eu des problèmes similaires avec l'élimination des paquets ! J'apprécierai vraiment votre aide
raminsj13
le 8 mars 2017
Je suis désolé que @raminsj13 n'ait pas encore reçu d'assistance, je vous informerai dès que j'aurai de l'aide.
alejandr0
le 8 mars 2017
Idem ici, les retransmissions de paquets qui ont été précédemment reçus, mais sans accusé de réception, ne sont pas rejetées. @joakimeriksson S'il vous plaît, aidez.
axlalvaro
le 8 mars 2017
Ce comportement ne respecte pas la rfc7252 4.5 qui parle de messages en double :
4.5. Message Deduplication
A recipient might receive the same Confirmable message (as indicated
by the Message ID and source endpoint) multiple times within the
EXCHANGE_LIFETIME (Section 4.8.2), for example, when its
Acknowledgement went missing or didn't reach the original sender
before the first timeout. The recipient SHOULD acknowledge each
duplicate copy of a Confirmable message using the same
Acknowledgement or Reset message but SHOULD process any request or
response in the message only once. This rule MAY be relaxed in case
the Confirmable message transports a request that is idempotent (see
Section 5.1) or can be handled in an idempotent fashion.
La CLÉ est
mais DEVRAIT traiter toute demande ou réponse dans le message __une seule fois__
cquijano
le 9 mars 2017
Oui tu as raison. Il s'agit d'une fonctionnalité manquante. Nous examinerons une implémentation minimale qui au moins ignorera les doublons du dernier paquet reçu (par exemple, ne sera pas envoyé à l'application). Mais toujours gérer les acks.
joakimeriksson
le 14 mars 2017
Salut tout le monde,
rencontrant également ce problème et impatient d'obtenir une solution !
Merci!
jcharlet
le 16 mars 2017
Merci beaucoup @joakimeriksson d' avoir répondu à ce problème, j'apprécie vraiment votre aide car il s'agit d'une fonctionnalité critique pour notre application, car les nœuds effectuent une action qui ne peut pas être effectuée deux fois.
J'espère que vous pourrez en faire la mise en œuvre bientôt.
alejandr0
le 17 mars 2017
J'ai le même problème. Serons-nous mis à jour lorsqu'il y aura un correctif ?
vcifani
le 28 mars 2017
Une mise à jour à ce sujet, @joakimeriksson ??
alejandr0
le 15 juin 2017
Ajout d'une liste de packages déjà traités, donc au cas où l'ACK est manqué, le message retransmis n'est plus traité.
Les messages sont identifiés par le MID, l'adresse IP et le port.
Il y a deux paramètres configurables :
COAP_CHECK_DUPLICATES_LIST_SIZE
Define the maximum number of messages to track
COAP_CHECK_DUPLICATES_MAX_SECONDS
Amount of seconds to wait until a message on the list is expired
therudo
le 24 nov. 2017
Questions connexes
Conrad2210
·
14Commentaires
ragbagger16
·
10Commentaires
lamnd09
·
75Commentaires
davidsantosb
·
7Commentaires
alignan
·
10Commentaires
Commentaire le plus utile
Oui tu as raison. Il s'agit d'une fonctionnalité manquante. Nous examinerons une implémentation minimale qui au moins ignorera les doublons du dernier paquet reçu (par exemple, ne sera pas envoyé à l'application). Mais toujours gérer les acks.