Você não pode selecionar mais de 25 tópicos Os tópicos devem começar com uma letra ou um número, podem incluir traços ('-') e podem ter até 35 caracteres.

Notes.txt 2.5KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061
  1. 20091009.1549 _M
  2. Copyright (C) 2009 ARM Research Labs, LLC
  3. SNF4CGP provides a high-performance, multi-threaded spam filter plugin for
  4. Communigate Pro using the Message Sniffer (SNFMulti) engine.
  5. http://www.communigate.com/CommuniGatePro/VirusScan.html
  6. http://www.communigate.com/CommuniGatePro/Helpers.html
  7. http://www.communigate.com/CommuniGatePro/Data.html#String
  8. The general design goals are (in no particular order):
  9. 1. Provide a customizable match between each possible SNF result code and
  10. each possible communigate response.
  11. 2. Provide comprehensive debugging and performance logging capabilities
  12. consistent with the way Communigate operates.
  13. 3. Provide a flexible message-hold capability to allow for additional processing
  14. by other software for quarantine operations or further message handing.
  15. 4. Provide the highest possible message handling performance.
  16. 5. Create an architecture that is easy to extend and support on multiple
  17. platforms.
  18. See Architecture.jpg for a drawing of the architecture. Note that the snap-shot
  19. is slightly out of spec. When the Architecture.jpg was snapped the thinking was
  20. that each Job in the pool would contain it's own dedicated scanner. Later during
  21. development it was decided that scanners should also be pooled and conserved and
  22. only bound to a job for as short a time as possible. The latest drawing shows
  23. this by connecting a Scanner Pool to the scan operation with a short loop and
  24. indicating that the scanner pool resides inside the Job pool with a small symbol
  25. in each. When we redraw this architectural diagram we will include these changes.
  26. The application uses threads in this way:
  27. * One thread sets up the application, reads requests, and ultimately closes
  28. down the application.
  29. * Another thread processes all finished jobs by pumping their output through
  30. cout and then recycling job objects.
  31. * Worker threads from a pool process each request.
  32. Resource contention is minimized wherever possible:
  33. - Ram allocation is conserved by pre-allocating and reusing buffers.
  34. - Scanners, Worker threads, and Jobs are allocated as needed and pooled.
  35. - Scanners are borrowed from a pool only long enough to scan a message and
  36. capture the results.
  37. - Configuration data is parsed and cached only when it has changed.
  38. - Worker threads are released back to the pool without waiting for IO to cout.
  39. - As much as possible thread interactions are reduced to reference passing
  40. in very short mutex protected functions.