Path: utzoo!attcan!uunet!bloom-beacon!athena.mit.edu!tytso From: tytso@athena.mit.edu (Theodore Y. Ts'o) Newsgroups: news.software.nntp Subject: Re: Idea for nntpd Message-ID: <14527@bloom-beacon.MIT.EDU> Date: 22 Sep 89 17:45:23 GMT References: <14506@bloom-beacon.MIT.EDU> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: tytso@athena.mit.edu (Theodore Y. Ts'o) Organization: Massachusetts Institute of Technology Lines: 28 In article flee@shire.cs.psu.edu (Felix Lee) writes: >In article <14506@bloom-beacon.MIT.EDU>, > Theodore Y. Tso proposes >a scheme to create a lock file for each article while nntpd is >receiving it. > >The question is, what do you tell site B when the article it tries to >offer you is being sent by site A? "Gotit" is wrong, if the A xmit >fails. Blocking until the lock goes away is unnecessary delay. The >best thing is to tell site B to ask again later. Actually, something which I forgot to mention is that currently the news system does currently block until site A finishes processing the article. The difference is that the nntpd forks a rnews that checks for the existence of /tmp/L and blocks until that file goes away. It would be more efficient for this to be handled at the NNTP layer. However, I'm not sure there's a NNTP code to send back that will cause nntpxmit to defer an article until later without aborting the entire transfer session. Is there a way to do such a thing, or will it require modification of nntpxmit as well? I was hoping for something that didn't require modification of nntpxmit, so I could run it on my site without worrying about what my neighbors run. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o bloom-beacon!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu Everybody's playing the game, but nobody's rules are the same!