Re: [core] Request for clarification of NSTART and concurrent requests

Thanks.  This is really helpful.

Suppose a server is processing a request from a client, and the client
sends a new request (new message id), but with the same token as the
outstanding request?  For example, the client may have restarted, used the
same source port, and chose the same token for a new request that it had
used in the previous request.  Would 4.29 be appropriate in this case as
well?  In addition, I think the server would have to avoid sending a
response when the outstanding request completed, because the client has
indicated by virtue of the token reuse that it has forgotten about the
original request.

Thanks,
Bryan

On Tue, Aug 16, 2022 at 6:13 AM Carsten Bormann <cabo@tzi.org> wrote:

> Thanks for the quick reply, Achim!
>
> Adding chapter and verse:
>
> > there are two options:
> >
> > - 4.29 "Too many requests"
>
> This is described in RFC 8516, which compares 4.29 to 5.03 by stating
> "However, the 4.29
>    code indicates that the too-frequent requests from the requesting
>    client are the reason for the overload.”
>
> So, the error is really client-induced and therefore has a 4.xx code.
>
> > - 5.03 "Service unavailable"
>
> This is described in Section 5.9.3.4 of RFC 7252:
> 5.03 Service Unavailable
>
> > both with a proper value for "Max. Age." (option 14).
>
> Which also explains the use of Max-Age, but RFC 8516 is a bit less terse
> about the use of that option (and the possible surprise by its default
> value).
>
> Grüße, Carsten
>
> >
> > best regards
> > Achim
> >
> > Am 15.08.22 um 22:40 schrieb Bryan Green:
> >> What would be the appropriate response to a CON request from a
> >> constrained coap server that had reached its limit of concurrent
> >> requests from a single client?
> >> For example if a server was only capable of handling one CON request per
> >> client at a time, and a CON request was received while the prior request
> >> was still being processed, should the server silently ignore the packet,
> >> or is there an appropriate response code to inform the client of the
> >> need to wait?
> >>
> >>
> >> On Mon, Aug 15, 2022 at 1:13 PM Bryan Green <bryan@aetheros.com
> >> <mailto:bryan@aetheros.com>> wrote:
> >>
> >>    Thank you very much for the response.  That answers my question.
> >>
> >>    -Bryan
> >>
> >>
> >>    On Mon, Aug 15, 2022 at 12:22 PM Carsten Bormann <cabo@tzi.org
> >>    <mailto:cabo@tzi.org>> wrote:
> >>
> >>        On 15. Aug 2022, at 21:19, Carsten Bormann <cabo@tzi.org
> >>        <mailto:cabo@tzi.org>> wrote:
> >>         >
> >>         > heavily suggested
> >>
> >>        heavily CONgested
> >>
> >>        Sorry about that surprising auto-correct.
> >>
> >>        Grüße, Carsten
> >>
> >>
> >> _______________________________________________
> >> core mailing list
> >> core@ietf.org
> >> https://www.ietf.org/mailman/listinfo/core
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core
>
>