On Tue, Mar 29, 2016 at 10:36:55PM +0000, Harlan Stenn wrote: > For a multitasking server, it could well be that one "thread" does the > ordinary NTP handling while another does the NTS work. The first thread > might say "I'm willing to wait N milliseconds before I reply to this > request", and if the NTS processing gets done in time then the > client_assoc info is ready in that response. If not, a "plain" response > goes back, the client sends a plain NTP packet as its next query, and > the server replies with NTP+NTS-client_assoc.
If the server is not able to respond in time (whatever that means), it shouldn't respond at all. The client will try again later. Responding with a plain NTP message would not help as the client would ignore the reply. Even if it didn't ignore it, the new request would have to be the same NTS message as before, because the server doesn't have the previous request. I doubt any server implementation would want to cache requests and replies. > I think it's a Bad Idea to make assumptions and "proactive restrictions" > about how to do these exchanges. What restrictions would you like to loose? The suspension of the NTS protocol with plain NTP messages you described seems to me like a major complication in the protocol, which would require the server to cache the client's requests. -- Miroslav Lichvar _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
