Text 83, 130 rader
Skriven 2005-02-13 19:34:54 av Maurice Kinal (1:153/401.1)
     Kommentar till text 82 av mark lewis (1:3634/12)
Ärende: talking to myself
=========================
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)