Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20

[Ted Lemon <[e-mail]>]

On Jul 11, 2019, at 7:39 PM, Tom Pusateri <[e-mail]> wrote:
> There is no back to back reconnect in the #2 case. The server shouldn’t accept the connection after sending a RETRY DELAY to this client. The client may ignore the RETRY DELAY but this doesn’t matter. It’s only a courtesy that the SERVER tells the client how long it has to wait.

I don’t know how the server refuses connections on a per-client basis.   We certainly don’t describe how to do that in the DSO RFC.  Practically speaking, unless the server is maintaining a list of all the clients that connect to it, it has no idea that client X that it just dropped is client Y that just connected.   Even if it does maintain such a list, it would be unusual for that to allow it to actually drop the connection immediately.   And supposing it does, that might just make the client reconnect a bit faster.   That is, if the SYN gets an RST in response, the client will just get -1 from connect() and call connect() again unless it has some kind of backoff strategy.