On Tue, 22 Jan 2002 [EMAIL PROTECTED] wrote: > > > On Mon, 21 Jan 2002, Davide Libenzi wrote: > > > On Sun, 20 Jan 2002 [EMAIL PROTECTED] wrote: > > > > > > > > > > > On Fri, 11 Jan 2002, Davide Libenzi wrote: > > > > > > > On Fri, 11 Jan 2002 [EMAIL PROTECTED] wrote: > > > > > > > > > Thanks very much Davide, and yes, I agree but when I looked into it I > > > > > didn't find a simple way to implement this for xmail. Seemed like I would > > > > > have to write the binary which would then need to talk to a service that > > > > > was running via sockets, etc. > > > > > > > > > > Would you have any tips on doing this or know where I can find some > > > > > existing info or standard on how this should be implemented otherwise it > > > > > seems like reinventing the wheel... > > > > > > > > There are so many sources that i'm not able to give you anything :) > > > > The architecture is very simple, on one side you've a server that will be > > > > probably written in Perl that will listen on a given port. On the other > > > > side a _very_thin_ client written in C ( it should not be more that 30Kb ) > > > > that is run by XMail, connect to the server, give it file and options and > > > > return a status. Very simple. > > > > You can even have a pool of servers with the C program that select one of > > > > these with a random function to achieve load distribution. > > > > > > > > > > > > > > > > > > > > - Davide > > > > > > > > > > > > - > > > > 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] > > > > > > > > > > Dear Davide, > > > > > > Thanks very much for your answer and yes I see this is in reality a simple > > > idea. > > > > > > (I thought I would answer you off-list by the way, as this subject doesn't > > > seem to be of great interest to most users.) > > > > > > And I do understand the idea that "there are so many sources I don't know > > > what to tell you" :) > > > > > > What I am basically looking at is running xmail on a system running > > > between 5,000-20,000 messages per day, and probably doing antivirus > > > filtering and various other custom operations on all traffic. > > > > > > Basically my idea was to implement something like fastcgi but I don't know > > > if maybe this isn't really a must? > > > > > > See, I have done a fair amount of perl, but creating the c binary + a perl > > > server answering on a socket is quite beyond what I have attempted in the > > > past and I was hoping to find an existing solution I could customize > > > rather than having to create something from scratch. If you do know of > > > places I could look, I would definitely appreciated it. One point I have > > > run into (and I have looked at the perl fastcgi docs) is that most of > > > these solutions/modules assume one already knows all about them. For > > > instance, I could not find answers to basic questions on the fastcgi perl > > > library such as "how does one keep a fastcgi perl script running?" ie - > > > does it have to be compiled/installed as a service? Or do I just need to > > > call the appropriate modules and then this happens automatically? And also > > > although I thought the idea of fastcgi was that the script answers up on a > > > particular tcp port, I could find no data on that and which port and how > > > it's configured, what about multithreading, etc. Which of course are key > > > points if I'm about to write a binary in C that will connect to the perl > > > script, etc. > > > > > > Anyway, I know this is a long message, if you don't mind giving out some > > > advice, I would definitely appreciate it. > > > > > > A last point is that maybe I am going overboard and I don't even need to > > > do this? That is, maybe I could just write my perl script and create an > > > .exe out of it and just have it execute every time? Seems like most people > > > are doing that but I don't think most xmail admins have custom filters on > > > all traffic. > > > > If your major use of this framework is anti virus filtering, it's useless > > because you're going to spawn a scan for each message and 80% of the cost > > is due DAT files loading and initial table building. > > You would need library access to an AV engine to do it efficiently. > > In this way the server initialize and remain active by cutting the boot > > cost for all requests. > > > > > > > > > > - Davide > > > > > > - > > 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] > > > > Yes, I am aware of the point on the virus scanning and I was planning on > doing this via some type of library call - ie - API call, etc. With this > in mind, ideally I could do both the "fastcgi" concept and perform the > antivirus via an API in order to get the best performance possible. > > But basically I have had a difficult time finding concrete ways to do the > fastcgi. (Probably for the antivirus API I will have to find some > commercial package with all the data I need to do this or there will be > concrete direction on it in any case, but I have not found this to be the > case with fastcgi.) > > Anyway, any advice or recommendation would be appreciated.
The real problem is not fast_cgi, the real problem is to have access to AV engines API. I do not know if AV Co. actually sells library access. - Davide - 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]
