RE: [sniffer] Call for beta testers... snfrv2r3b1
I think the problem is in the file extension. It should not be .com, but rather .cmd. Hope this helps, _M At 12:32 PM 3/25/2004, you wrote: Hi, When I try to run the .com file, I get an error. I have attached the error dialog box and a copy of the .com file (name altered to .co_) that I am using. Can you see what I am doing wrong? The program seems to be running OK in normal mode. Thanks, Bill Morgan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: Wednesday, March 17, 2004 1:05 PM To: [EMAIL PROTECTED] Subject: [sniffer] Call for beta testers... snfrv2r3b1 Hello folks, I know folks are anxious to get their hands on this version so I'm going to play this beta round a little looser than usual. Version 2-3b1 implements a persistent mode feature for our cellular peer-server technology. Launching a persistent instance of Message Sniffer has the effect of creating a daemon so that all other instances will elect to be clients. We observed a DRAMATIC improvement in system performance on our NT4/Imail/Declude test bed. In static tests on my Toshiba 6100 we saw no memory leaks and consistent performance over the past 18+ hours of testing. This included several tests with more than 100+ concurrent client instances - all without failure and without making the system unresponsive (though the WinXP file system did start to show signs of strain). This beta is for the windows platform only... once we're happy with this version will will make the source and *nix versions available as always. Windows platform users who are interested in testing the new beta should download the following file: http://www.sortmonster.com/MessageSniffer/Betas/snfrv2r3b1.zip The file contains an executable and a short readme file. We are going to be extremely busy for the next few hours so we won't be able to provide support on this until later this evening. We have many updates and rulebase mods to attend to at the moment since we shifted resources heavily toward development last evening and through the night... The current spam storm continues to rage with more than 500 core rule-base changes yesterday alone! Be careful. Backup your current production version. Watch carefully. Enjoy :-) _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Call for beta testers... snfrv2r3b1
Paul, Did you have the persistent sniffer.exe running when this log was generated? Groet, (regards) -- ing. Michiel Prins bsc [EMAIL PROTECTED] SOS Small Office Solutions / Reject / Wannepad 27 - 1066 HW -Amsterdam t.+31(0)20-4082627 - f.+31-(0)20-4082628 -- Consultancy - Installation - Maintenance Network Security - Internet - E-mail Software Development - Project Management -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peer-to-Peer, LLC Sent: donderdag 18 maart 2004 15:15 To: [EMAIL PROTECTED] Subject: RE: [sniffer] Call for beta testers... snfrv2r3b1 Groet, RE: MDaemon: I guess I'm confused on how to determine the Content Filter poll time. Here's a (.txt snippet of my CF log file which does not show a delay (or at least to my level of skill abilities; which is minimal by-the-way). I'll be happy to test some things on our server if you have any specific instructions for me. We share the same objectives. Regards, Paul Roulier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michiel Prins Sent: Thursday, March 18, 2004 2:59 AM To: [EMAIL PROTECTED] Subject: RE: [sniffer] Call for beta testers... snfrv2r3b1 Paul, Aren't you having problems that the polling times just make the waiting times in the CF longer? While normally my bottleneck was the loading of the rulebase, now it's the polling time which is way longer. Pete, With Mdaemon, where there's only one message being processed at a time, and there's no multithreading content filter yet, I would like to be able to set polling time to a fixed 25 or 30 ms. Normally, loading the rulebase would take 200, with polling I understand this could be reduced to 30 ms - if the time can be set to a fixed ms. Could you also consider the other options I asked? Groet, (regards) -- ing. Michiel Prins bsc [EMAIL PROTECTED] SOS Small Office Solutions / Reject / Wannepad 27 - 1066 HW -Amsterdam t.+31(0)20-4082627 - f.+31-(0)20-4082628 -- Consultancy - Installation - Maintenance Network Security - Internet - E-mail Software Development - Project Management -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peer-to-Peer, LLC Sent: donderdag 18 maart 2004 4:21 To: [EMAIL PROTECTED] Subject: RE: [sniffer] Call for beta testers... snfrv2r3b1 _M, FYI: Have been running the beta ver 2.3b1 on MDaemon 7.0.0 for several hours now and all is stable. Everything is performing as advertised... paul roulier -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pete McNeil Sent: Wednesday, March 17, 2004 2:05 PM To: [EMAIL PROTECTED] Subject: [sniffer] Call for beta testers... snfrv2r3b1 Hello folks, I know folks are anxious to get their hands on this version so I'm going to play this beta round a little looser than usual. Version 2-3b1 implements a persistent mode feature for our cellular peer-server technology. Launching a persistent instance of Message Sniffer has the effect of creating a daemon so that all other instances will elect to be clients. We observed a DRAMATIC improvement in system performance on our NT4/Imail/Declude test bed. In static tests on my Toshiba 6100 we saw no memory leaks and consistent performance over the past 18+ hours of testing. This included several tests with more than 100+ concurrent client instances - all without failure and without making the system unresponsive (though the WinXP file system did start to show signs of strain). This beta is for the windows platform only... once we're happy with this version will will make the source and *nix versions available as always. Windows platform users who are interested in testing the new beta should download the following file: http://www.sortmonster.com/MessageSniffer/Betas/snfrv2r3b1.zip The file contains an executable and a short readme file. We are going to be extremely busy for the next few hours so we won't be able to provide support on this until later this evening. We have many updates and rulebase mods to attend to at the moment since we shifted resources heavily toward development last evening and through the night... The current spam storm continues to rage with more than 500 core rule-base changes yesterday alone! Be careful. Backup your current production version. Watch carefully. Enjoy :-) _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com
Re: [sniffer] Call for beta testers... snfrv2r3b1
At 08:08 PM 3/17/2004, you wrote: What is the number after Polled waited: That is the number of milliseconds the persistent server waited to poll the working directory for more jobs. This number will increase each time no jobs are found. When a job is found the persistent server will not wait before looking for the next job - so you will only see these messages when the persistent server finds no messages to process. I also noticed that when many emails are coming in I still see multiple Sniffer.exe programs running. That is normal. Each message being processed will load an instance of Sniffer. With the persistent server running all of the other instances should elect to be clients so they will simply record a job record (.QUE) and wait for the server instance to process their message (.FIN). Then they will pick up the result and exit - reporting the result back to the calling program. Client instances take very little memory and spend most of their time sleeping so they require very few CPU or IO resources. _M This E-Mail came from the Message Sniffer mailing list. For information and (un)subscription instructions go to http://www.sortmonster.com/MessageSniffer/Help/Help.html
RE: [sniffer] Call for beta testers... snfrv2r3b1
I am still working a problem at our hosting facility (a t1 is down) so it will be a while before I can get back to the list, however I wanted to clear this one up to minimize confusion. A persistent server instance uses a dynamic poll timing algorithm to minimize system loads while maximizing response times. It is probably not appropriate to use a fixed time interval for polling since this can cause unnecessary system loading and since the dynamic approach we're using has proven in our labs to offer improved all-around performance. When the server has processed a job for a client it polls again immediately without waiting. If no job is found then it will wait a short time before polling again. If there are no available clients on a poll then the wait time between polls will increase in a natural spiral based on a Fibonacci sequence. This wait time will continue to expand until either a new job is found or the limit is reached. The limit is currently set to 1/2 the maximum client base wait time - which amounts to 4 seconds. It's worth noting that in order for a server instance to get to a given wait time (such as 4 seconds) there must have been no messages to process for that amount of time. It's also worth noting that some folks using spamassassin regularly report message processing times on the order of 5 to 9+ full seconds for each message (I just read this on the sa list). Based on these two factors I've considered that waiting a maximum of 4 seconds to process a message after a 4 second lull in activity is probably not an issue - especially considering that once the message is processed it will likely take only an additional 30ms or so on average for a total of 4.030 sec (ymmv). This also represents the worst case given the current tuning parameters... Once a job is found then the wait time is reset to the minimum. Once again, the first poll after a job has been processed has no wait time... so if there is a burst of message activity after a 4+ second lull, the first message waits a maximum of 4 seconds and the rest wait only a few tens of milliseconds. The monitor messages you are seeing are only a debugging/tuning aid and they will be removed for the production version. The timing message is only emitted when the server instance has found no messages to process during the previous poll. Hope this helps, _M PS: In a situation where peer-server instances become mixed it is possible for more than one server instance to become active for a period of time. The Fibonacci timing spiral helps to ensure a distributed scattering of lock requests when multiple instances are active - thus reducing collisions. At 03:04 PM 3/17/2004, you wrote: Pete, After my previous message, I noticed that 'polling' really means that Sniffer is waiting that many milliseconds before it processes another e-mail. If I'm seeing this correctly, I'd like to request another option available when spawning the persistent exe: /polling:x (where x = a fixed amount of milliseconds between polling) Groet, (regards) -- ing. Michiel Prins bsc [EMAIL PROTECTED] SOS Small Office Solutions / Reject / Wannepad 27 - 1066 HW -Amsterdam t.+31(0)20-4082627 - f.+31-(0)20-4082628 -- Consultancy - Installation - Maintenance Network Security - Internet - E-mail Software Development - Project Management -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete McNeil Sent: woensdag 17 maart 2004 20:05 To: [EMAIL PROTECTED] Subject: [sniffer] Call for beta testers... snfrv2r3b1 Hello folks, I know folks are anxious to get their hands on this version so I'm going to play this beta round a little looser than usual. Version 2-3b1 implements a persistent mode feature for our cellular peer-server technology. Launching a persistent instance of Message Sniffer has the effect of creating a daemon so that all other instances will elect to be clients. We observed a DRAMATIC improvement in system performance on our NT4/Imail/Declude test bed. In static tests on my Toshiba 6100 we saw no memory leaks and consistent performance over the past 18+ hours of testing. This included several tests with more than 100+ concurrent client instances - all without failure and without making the system unresponsive (though the WinXP file system did start to show signs of strain). This beta is for the windows platform only... once we're happy with this version will will make the source and *nix versions available as always. Windows platform users who are interested in testing the new beta should download the following file: http://www.sortmonster.com/MessageSniffer/Betas/snfrv2r3b1.zip The file contains an executable and a short readme file. We are going to be extremely busy for the next few hours so we won't be able to provide support on this until later
