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