Closed henrywang closed 1 year ago
The T01 protocol is used for Client <-> rendezvous communications.
TL;DR: it's not a bug
In order for the TO1 protocol to work (device contacts rendezvous to get an address to contact its owner), the TO0 protocol must have been already performed (rendezvous is contacted by the owner to get a TO1d blob and the OV with a GUID, so that the rendezvous can know where to redirect the devices).
The log of the rendezvous server shows that it's rejecting a TO1HelloRV
from a client since it has just started working, then it gets a couple of TO1D
( starting with the message type msg/20
: 192.168.100.1:38486 "POST /fdo/101/msg/20 HTTP/1.1" 200 "-" "-" 1.984493ms
) and it's storing some GUIDs as a result of that. Later it is processing the TO1 protocol as it should know now that it has GUIDs stored:
192.168.100.50:59470 "POST /fdo/101/msg/30 HTTP/1.1" 200 "-" "-" 658.496µs
192.168.100.50:59470 "POST /fdo/101/msg/32 HTTP/1.1" 200 "-" "-" 1.457304ms
the msg/30
, msg/32
message types show that the client is properly communicating with the rendezvous, the rendezvous (not shown in the logs) is sending msg/31
, msg/33
, as it should (see this).
So, what I want to say is that timing is important here, it's a MUST to return a ResourceNotFound
when no GUIDs are found by the rendezvous according to the GUID given by the client. Then, as the rendezvous gets GUIDs it is able to fulfill the requests of the client. So, not a bug.
Closing this as there is no action to take.
When I run FDO server or aio tests, 80% of times I can get T01 error. This error doesn't block fdo functions I tested.
For fdo services:
For fdo-aio: