Comments (6)
kmnichols
commented on July 4, 2024
This message only happens if you are using delivery confirmation. That means a call back is set for when the message (that is, all publications needed to make up that message) have been seen in the iblt of some other member. The output you sent says that Message #10 didn't reach the Collection, but the output you are showing is all alice-38782, so I don't understand the basis for saying that another peer has received message 10? Have you been monitoring packets?
from dct.
tylerliu
commented on July 4, 2024
Here's the log from the receiver:
Application entity device:frontdoor-38780 received message:
capability = lock
topic = command
location = all
arguments = lock
message creation time = 1626927043171209 (2.60143mS)
message body: Message number 9 from operator:alice-38782
Application entity device:frontdoor-38780 received message:
capability = lock
topic = command
location = all
arguments = unlock
message creation time = 1626927044173529 (13.3221mS)
message body: Message number 10 from operator:alice-38782
device:frontdoor-38780 msg #7 published to Collection.
device:frontdoor-38780 msg #7 published to Collection.
Application entity device:frontdoor-38780 received message:
capability = lock
topic = command
location = all
arguments = lock
message creation time = 1626927045175254 (2.85373mS)
message body: Message number 11 from operator:alice-38782
device:frontdoor-38780 msg #9 published to Collection.
device:frontdoor-38780 msg #9 published to Collection.
from dct.
kmnichols
commented on July 4, 2024
What appears to be happening here is that Message 10 was received at frontdoor-38780 but alice-38782 did not see it in an iblt in an Interest until after Message 10 expired. Message 10 was not received as quickly (probably due to competition with other publishers) as the other messages (the 13.3ms vs 2.6+ ms) but that should not be causing the problem. We've seen some other evidence of scheduled events being grouped oddly so the Interest could have been delayed or even dropped. We will continue to try to track this down in the scheduler (or maybe NFD?), but I did add some code to app2.cpp that gives the time from creation till expiration or confirmed publication that can be useful to see what's happening when. You could turn on logging, but that does put out a huge volume of data and sometimes changes conditions for timing problems. If you are monitoring packets, you might observe what's happening at that level.
from dct.
kmnichols
commented on July 4, 2024
We found various issues that appeared to be causing the behavior and other less than desirable behavior. Try the latest commit that should fix the issue.
from dct.
tylerliu
commented on July 4, 2024
The problem still persists.
The sender(Alice):
operator:alice-41633 msg #7 published to Collection.
operator:alice-41633 msg #8 published to Collection.
Application entity operator:alice-41633 received message:
capability = lock
topic = event
location = frontdoor
arguments = unlocked
message creation time = 1627603356467284 (2.13703mS)
message body: Message number 3 from device:frontdoor-41631
operator:alice-41633 msg #9 timed out without reaching Collection.
operator:alice-41633 msg #10 published to Collection.
Application entity operator:alice-41633 received message:
capability = lock
topic = event
location = frontdoor
arguments = locked
message creation time = 1627603357482364 (3.15655mS)
message body: Message number 4 from device:frontdoor-41631
The Receiver(front door):
Application entity device:frontdoor-41631 received message:
capability = lock
topic = command
location = all
arguments = unlock
message creation time = 1627603356464810 (2.36148mS)
message body: Message number 8 from operator:alice-41633
device:frontdoor-41631 msg #4 published to Collection.
Application entity device:frontdoor-41631 received message:
capability = lock
topic = command
location = all
arguments = lock
message creation time = 1627603357467212 (15.0168mS)
message body: Message number 9 from operator:alice-41633
device:frontdoor-41631 msg #5 published to Collection.
Application entity device:frontdoor-41631 received message:
capability = lock
topic = command
location = all
arguments = lock
message creation time = 1627603358473359 (2.88783mS)
message body: Message number 10 from operator:alice-41633
from dct.
kmnichols
commented on July 4, 2024
You don't appear to have pulled down the new code since the output format is different in the new app2.
from dct.
Related Issues (7)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dct.