home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / admin / 6948 < prev    next >
Encoding:
Internet Message Format  |  1993-01-07  |  2.4 KB
  1. Path: sparky!uunet!enterpoop.mit.edu!senator-bedfellow.mit.edu!athena.mit.edu!jik
  2. From: jik@athena.mit.edu (Jonathan I. Kamens)
  3. Newsgroups: comp.unix.admin
  4. Subject: Re: mail servers and sendmail -- disk space vs. speed vs. file table trade-offs
  5. Date: 7 Jan 1993 15:54:01 GMT
  6. Organization: Massachusetts Institute of Technology
  7. Lines: 35
  8. Distribution: world
  9. Message-ID: <1ihjmpINN38i@senator-bedfellow.MIT.EDU>
  10. References: <1iesvgINN4l0@senator-bedfellow.MIT.EDU> <3584@aegis.or.jp>
  11. NNTP-Posting-Host: pit-manager.mit.edu
  12.  
  13. In article <3584@aegis.or.jp>, davidg@aegis.or.jp (Dave McLane) writes:
  14. |> Ralph Sims
  15. |> <ralphs@halycyon.com> sent me a trick version of mini-inews that
  16. |> didn't just send across the network to the real inews on the server,
  17. |> but put the article to be posted in a 'printer queue' and then
  18. |> returned to the user. The code is quite small (8K) and I could post
  19. |> it here if you/anybody was interested.
  20. |> 
  21. |> Perhaps you could use something similar to queue the requests to 
  22. |> sendmail.
  23.  
  24. When you've got users posting small numbers of messages from multiple client
  25. hosts, this is fine.
  26.  
  27. However, all of the messages in this case are outbound messages from a single
  28. host.  Sendmail already *has* the functionality you suggest, i.e., the queuing
  29. delivery mode that I mentioned in my previous posting.  As I said before, I
  30. can't really use that because if I do, a large number of requests in a short
  31. period of time can fill the disks on my mail server.
  32.  
  33. I guess that if I wanted to *completely* parallel the news posting model you
  34. suggest in my server, then I would have to set it up to refuse delivery of
  35. incoming requests, at the sendmail level, when there aren't currently enough
  36. resources to process the requests.  That's not really possible, because it's
  37. not *possible* to know when there are going to be enough resources available to
  38. process a request.  In the case of the request that caused me to notice this
  39. problem in the first place, it was a single request that overwhelmed the
  40. workstation, and I couldn't have known that the request would be
  41. resource-consuming without parsing it and trying to deliver (since only then
  42. would I have discovered the amount of data being transferred and possibly the
  43. fact that the sender's SMTP server was very slow.
  44.  
  45. -- 
  46. Jonathan Kamens                                         jik@MIT.Edu
  47. Aktis, Inc.                                 Moderator, news.answers
  48.