home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / vmsnet / internal / 1711 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  3.2 KB
  1. Path: sparky!uunet!mcsun!ieunet!vms.eurokom.ie!t_wade
  2. From: t_wade@vms.eurokom.ie
  3. Newsgroups: vmsnet.internals
  4. Subject: Re: Received Bytes Accounting
  5. Message-ID: <1992Dec22.122330.12171@vms.eurokom.ie>
  6. Date: 22 Dec 92 12:23:30 CET
  7. References: <01GSFKS4THCYAFTSR3@accuwx.com> <1gutvmINNlv7@gap.caltech.edu>
  8. Organization: EuroKom Conferencing Service
  9. Lines: 50
  10.  
  11. I am surprised at the amount of aggression that this query has generated.
  12. There is no general `ideal' model for charging usage -- it all depends on
  13. what type of service you are providing.
  14.  
  15. > Please, tell us for what applications you think that "number of bytes written
  16. > to the terminal" is in any way a useful measure of the usefulness of the
  17. > session.  I can't think of any.
  18.  
  19. If the service you provide is information, then this is a pretty good model.
  20. For example, consider a service that provides various bulletin board type
  21. services (News, conferencing etc).  A reasonable approximation is charging
  22. by elapsed time.  The problem here is that one user will get his information
  23. interactively, and another will do the equivalent of EXTRACT/UNSEEN/ALL
  24. to a file, and download it with Kermit.  He will be charged a fraction of
  25. the first person's charge, but he gets the same `service' (the same
  26. information).  Of course, you could argue that by using the machine longer,
  27. the first user is consuming more resources and should pay more, but this
  28. might be easier on your machine than a short CPU and I/O intensive session.
  29. You might wish to charge for the amount of data received, irrespective of
  30. whether it is TYPEd, FTP'ed, MAILed or Kermited.
  31.  
  32. The counterexample of the physicist with the 8 hour batch job that produces
  33. 1 line of output is valid, but not relevent *if you don't provide this type
  34. of service*.
  35.  
  36. It is possible to use combined CPU, elapsed time and I/O count to approximate
  37. this, but my point is that there are scenarios where charging by volume of
  38. data (irrespective of how it is downloaded) is a good charging model.  The
  39. original query was perfectly reasonable.
  40.  
  41. As a first cut, what about replacing the Start I/O routine with your own, which
  42. notes the byte count and PID from the IRP, adds the count to a field that
  43. ACCOUNTING will save, and invokes the original Start I/O ?  Anyone care to
  44. pinpoint the flaws/pitfalls in this approach ?
  45.  
  46. Incidentally, the code to do this is already written.  Login sessions using
  47. VAX PSI (over X25 networks) are logged to the PSIACCOUNTING file including
  48. the volume of data sent and received.  This is presumably because most public
  49. X25 networks charge by volume.
  50.  
  51. ------------------------------------------------------------------------------
  52. Tom Wade        | Internet: T.Wade@vms.eurokom.ie  (all domain mailers).
  53. Network Manager | DEC Enet: DECWRL::"t.wade@vms.eurokom.ie"  (VMS Mail)
  54. EuroKom         | PSI-Mail: PSI%272431001992::_T_WADE
  55. UCD Belfield    | JANET:    t.wade%ie.eurokom.vms@UK.AC.EARN-RELAY
  56. Dublin 4        | X400:     g=tom;s=wade;o=eurokom;p=eurokom;a=eirmail400;c=ie
  57. Ireland         | Telex:       (0500) 91178 UCD EI  ("TO: WADE" at start)
  58. -------------------+----------------------------------------------------------
  59. Tel: +353-1-2830555|  Official Disclaimer:  "This is not a disclaimer"
  60. Fax: +353-1-2838605|          Unix  ....  Just say No !
  61.