Yes, there is a client called clamdscan that can call clamd. ClamD can = stay running. However, that does not reduce the number of processes running. The same number of processes would need to be launched per email, and = there would be one additional process running overall (ClamD). =20
There is one limitation in that ClamD cannot be run on a separate server like SpamD can. All the the client portion of ClamAV does is send the = full path to the file or folder that needs to be scanned. SpamC actually = sends the file over the wire to SpamD. I wish ClamAV shot the file over the = wire, because then I would cluster ClamD on a bunch of FreeBSD boxes like I = did with SpamD. Another idea I had was to merge the AV functions into SpamD somehow. If I did that, then I would just use SpamC, and SpamD would = handle the spam and virus scanning. That solution would be nice because it = would mean the message only needed to get sent over the wire once and the = email servers would not need to run AV software. Regarding merging everything into one process, I have been thinking down similar lines to what you are talking about. I have been thinking about rewriting the perl script in VC++, and then merging the SpamC and client = AV code into that one VC++ project. That would reduce the number of = launched processes to one per email hit, which would be a huge improvement over = my existing solution. Then if/when there are dll hooks for filters in = XMail, I could quickly recompile my VC++ code as a dll. =20 I have written ISAPI and WSAPI stuff before for IIS and Website Pro, so = I have seen first hand the gains when switching from a CGI to an ISAPI. = The gains are huge. In the case of XMail, the filters are perfect = candidates for writing as in-process dll files instead of spawning additional processes. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] = On Behalf Of Jason J. Ellingson Sent: Friday, November 05, 2004 5:01 PM To: [EMAIL PROTECTED] Subject: [xmail] Re: [****SPAM****] RE: Re: Spam Filters Couldn't you write a program to pass the message path to a memory = resident antivirus? I know Grisoft AVG has an easy to use COM interface. That = would eliminate a process load there. That same program to call the AV COM could have SPAMC code integrated = into it... resulting in just one process truly being called per email. I think that is the closest you could get. ------------------------------------------------------------ Jason J Ellingson Technical Consultant 615.301.1682 : nashville 612.605.1132 : minneapolis www.ellingson.com [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] = On Behalf Of Shiloh Jennings Sent: Friday, November 05, 2004 10:55 AM To: [EMAIL PROTECTED] Subject: [xmail] Re: [****SPAM****] RE: Re: Spam Filters I admit some performance is currently lost on Cygwin. However, this is = =3D not really what concerns me performance wise. The biggest performance =3D problem I see is the number of processes getting launched per email, not the use = =3D of Cygwin vs native Win32 compile. As I mentioned, there is a SpamC that = =3D you can build from source included with SA3 that is a native build and not a Cygwin build. But the performance difference between launching a native Win32 version of SpamC and launching a Cygwin version of SpamC is =3D nothing compared to the performance hit we see from launching so many processes = =3D per hit to begin with. Here are the five processes that we launch for each email: 1) perl.exe 2) cmd.exe 3) spamc.exe 4) cmd.exe 5) clamscan.exe As we all know, launching processes on Windows hurts performance. We = =3D need to be spawning threads instead of new processes. On Linux, launching another process is not nearly as much of a performance cost. The =3D existing filter design would be fine under Linux, even though it suffers under Windows. What I would love to see on the XMail build for Windows is an option to use dll files instead of launching processes for the filters. = =3D If that were the case, I would write a dll that handled connecting to clamd = =3D & spamd over tcp, and my dll would replace all of the code that is =3D currently in my perl script for handling parsing and logic regarding the replies = =3D from clam & sa. Then we could see real performance gain under Windows. I am = =3D not all that worried about the performance lost to Cygwin, because it is a fraction of the performance we are loosing to launching additional processes. As soon as we can hook a dll file into XMail for filters, = =3D then I will get excited and write all of the stuff in VC++ as a dll. The existing design we use works. I am not complaining. But I would = =3D love to be able to write all of it as one dll file that ran in process. Then = =3D the only process other than XMail that would need to be running would be clamd.exe. We would not need the performance expense of launching five = =3D new processes per email. Adding the option of dll filters would be enough = =3D of an improvement to get the Windows version of XMail on par with the Linux version of XMail. - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
