ietf-nntp Requirement for timeout close unclear
Clive D.W. Feather
clive at demon.net
Fri Jul 6 08:00:30 PDT 2001
Russ Allbery said:
>> And should the client have timeout restrictions as well ?
> I don't really see the point of putting timeout restrictions in the
> standard in the first place, since I think it's a matter of site
> configuration, so I'm not the one to ask. It doesn't bother me enough to
> reopen the previous discussion, though.
The present wording says that the server
- may timeout waiting for the client
- must not timeout in less than N seconds
Both might be reasonable limitations to put on a client.
>> We actually say that servers should give a 400 response to any command
>> if they need to terminate the connection, or a 401 to give advance
>> warning.
> This provision isn't at all useful to me. It requires that the server
> wait for the client to send another command before telling it that the
> server is being shut down, which is entirely the wrong timing model for
> INN.
Yes, I know that's not what those responses were designed for.
>> I wouldn't object to us saying that the server MAY send a 400 (or 404,
>> perhaps, since that code is unused ?) to mean a timeout-drop, provided
>> that we also note that the client might not see it.
> I think that Andrew's right and that the best thing to do is to simply
> drop the connection without sending anything at all.
Possibly. On the other hand, finding a "404 you took too long" in the
incoming stream might help in debugging problems.
> Hm. Do we have the same problem that SMTP does, namely that if the post
> is accepted but the response is lost, the client may assume that it needs
> to send it again, resulting in duplicates? If so, how do we fix that?
The uniqueness of message-IDs.
--
Clive D.W. Feather | Work: <clive at demon.net> | Tel: +44 20 8371 1138
Internet Expert | Home: <clive at davros.org> | Fax: +44 20 8371 1037
Demon Internet | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc | | Mobile: +44 7973 377646
More information about the ietf-nntp
mailing list