Subj : talking to myself To : mark lewis From : Maurice Kinal Date : Sun Feb 13 2005 07:34 pm Hey mark! Feb 13 21:10 05, mark lewis wrote to Maurice Kinal: MK>> Why waste the bytes and processing time for absolutely no good MK>> reason to man or machine? ml> no, they are to identify that specific message within a 3 year time ml> period... the address postion of the MSGID is also significant ;) It still isn't a "standard" as far as I am aware of. A missing MSGID certainly wouldn't be any worse then a phoney-baloney one or a duped one on a nonduped message, perhaps even better in the grand scheme of things. MK>> Yeah. I thought of that but then reconsidered. A complete MK>> waste of time seeing it is totally meaningless anyhow, MK>> networkingly-speaking. ml> nah, not really... i know of at least one individual who designed and ml> wrote a MSGID "server" for his stuff... granted, only his homebrew ml> software uses it... his server is a simple daemon that sits waiting ml> for a request for a new serial number... it spits one out, increments ml> it and waits for another request... at some point, it stores the ml> current number in a small datafile on the drive... That is sort of what the one I am playing with does but it isn't anything as serious ... yet. Still playing with it off and on. I am hopeful I will stumble across a good solution without causing any system too much grief, especially mine. MK>> Where is the joy in that? ;-) ml> hehe, ya know? Not yet. Hopefully soon before I get too frustrated with it all. Jeez two lousy extra stinkin' bytes would have made this sucker sing. Sigh. ml> i think part of the problem with the MSGID spec is ml> that the author put in the notation about "leaving it to the ml> implementor to figure out how to generate the serial number" ;) Right. Sounds likes some MS-ish "standard" to me. Some universal ID eh? ml> folk took that as a challenge and tried all kinds of ways of ml> generating serial numbers... some even went down the wrong trail and ml> used CRC32's of something without even thinking that there's a ml> limited number of CRC32s /and/ that there is a very real possibility ml> of creating a duplicate from two very different sources ;) Right. I think that is the plus of using the address on the first part of the field, prior to the space. I could employ the point system to clients and thus avoid worrying about two different users creating the exact same second part in the same message area, one of which would be considered a phoney dupe without that sort of override on a multiuser system. It could happen! Something like this acts as a builtin defence against that occuring ... if it did occur ... which it could. ml> nothing has been said about when to store the memory contents of the ml> serial counter to had media... that doesn't have to be done every ml> time, TTBOMK... sendmail and others do this very thing... have you ml> thought to look in their code and see what they are doing? O:) No. Personally I'd prefer a homegrown Fido solution to fix a Fido problem. ml> that's solely because the spec wasn't made mandatory as well as the ml> "rubbish" about "leaving it to the implementor" and such... I agree. ml> spec had been made mandatory and the method of generating the number ml> had been hammered down as well as what, exactly, is meant to be the ml> "address of the originating machine", then we'd not be having this ml> particular problem (or discussion, for that matter) O:) Could very well be true. We'll never know that for sure though and here we are talking about that very issue. Do you think it is a bad thing that we are discussing it at all? ml> possible... let's also not forget that some dupe detection routines ml> are a CRC32 on the header and possibly some of the first XX bytes of ml> the message body... we already know, and i mentioned it above, that ml> CRC32s are limited and are able to be duplicated with very different ml> input ;) Right. I can't see that being a viable or desirable solution to true dupe checking. I am not even sure I would want to go through all the hoops to catch a true dupe, MSGID or otherwise. However if it were a more serious problem then it currently is here I might change my tune rather quickly. The so-called dupes that aren't dupes (duped MSGID) bother me more especially the ones I don't even know about. Funny how that works. I am not even positive there are such critters other then the ones that manage to make it here to my dupe file. Very strange. ml> "empty" message bodies, it approached some 200 messages a second... Right. I was trying that the other night trying to see how many it could generate before generating a dupe ID on a nonduped message. Watching the numbers fly by got me tired rather quickly. They were unreadable given the speed. ml> on another, much faster machine, the speed for the same test clocked ml> upwards of 500 or so messages per second... granted, they were all ml> empty bodies but the header stuff and such all took time to create ml> and stuff into the message abse format... Right. I am not sure exactly how many this one generated of simular "messages" per second but I guesstimate well over 1000/sec. I think that is a conservative guesstimate too. I may check later to be sure if I get bored ... again. :-) ml> from there... it still has to load and process the message body text ml> file from the disk, though... Right. That would slow things down noticeably. ml> should i mention that the above tool is written in pascal? i have no ml> idea what it'd take to "port" it to perl but i am confident that it'd ml> be quite a bit slower on the same boxes ;) Hm. Interesting. I haven't seen any programs on Linux compiled from pascal so I wouldn't place a bet on it. Perl on Linux is a different breed of animal then it is on any other platform, that is for sure. I have seen perl on Win98 and it definetly isn't the same or as powerful as it is on Linux. Mind you that isn't really a fair comparison ... is it? Life is good, Maurice --- Msged/LNX 6.1.2 * Origin: Coffin Point - Ladysmith, BC Canada (1:153/401.1) .