Hey mark!

Feb 09 12:32 05, mark lewis wrote to Maurice Kinal:

 MK>> I need more bytes!!!  :-)

 ml> in reality, no you don't... what you need to do is to not restrict 
 ml> yourself to using the clock to generate the MSGID info... think about 
 ml> it... what happens if your clock gets set back? ;)

Right.  I have considered that which is why I use UTC on the server(s).  No
daylight savings, etc.  Also I am thinking of using a different source to
set the network time, say a gps clock for example.  That would be a
relatively inexpensive way to ensure that machines are more or less in
sync.  Not a great method but better then nothing and totally relying on
individual RTC clocks which may or may not be getting it "right",
whatever that really means.

 ml> if you want something that i've been using for years, you are welcome 
 ml> to it... however, in total reality, all you need is a serial counter 
 ml> that gets incremented each time it is used... what i use seperates 
 ml> the MSGID serial number into sections for multinode operations and 
 ml> allows for each node to generate some 8000 messages per day...

Sounds very interesting.  I don't think that 8000 messages a day is going
to be a limiting factor here at Kumalockasun.

 ml> software only does 255 nodes so that gives you an idea of the 
 ml> quantity of messages able to be generated... in addition, there is a 
 ml> serial counter that is rewound each day as well as a partial 
 ml> timedate...

I've been looking at an approach simular to what you seem to be saying. 
Also it akes sense that the MSGID should be generated by the common server
as apposed to each client generating it's own.  That way nobody requires
any special software other then some way of creating new messages and
reading any messages originating outside their particular box.  I believe
this is a better approach to winning over new users to Fido as well as
retaining the few we may or may not have.

 ml> in any case, a plain jane serial counter that your software 
 ml> increments is the simplist and easiest... i never have figured out 
 ml> whay everyone wanted to (way back when and still do today) jump on 
 ml> the clock counter...

The thing is that information is already there (DateTime for instance) so
why not use it?  The limiting factor is the eight charaters in the second
part of the MSGID and keeping it both meaningful and standardized.  I am
definetly not a fan of generating a random "number" as that ups
the processing time and is not always all that random depending on too many
factors.  Also having a standardized form speeds up dupe checking so that
only makes sense to have something like the MSGID in the first place.  The
real problem is that nobody seems to have put too much real thought into
the idea or went far enough with it.  Also I don't want the generation part
to rely on opening any extra datafile or keep track of some variable for
each and every user.  Once the function has completed it's task that should
be it.  Then it is up to some other function or application as to
transportation and delivery of those messages and if the MSGID has some
useable standard that could be employed in the assistance of delivery of
said messages.  This has the potential of a better 
accounting system without any additional overhead.  No?

 PE>> There is no requirement for there to be a MSGID kludge, and can you
 PE>> honestly say that you have NEVER been at risk of violating the MSGID
 PE>> standard, ie there was no possibility that you ever generated two
 PE>> MSGID's the same within any 3 year period?  I certainly can't.

How about forever?  I think with some REAL standard the possibilty exists
for every message that isn't REALLY a dupe to be truly unique for all time.
 Yes it can and probably will screw up some{where,time} but in all
probability it will be a reduction of screwups as to the currently
acceptable standard.

 ml> The identifier part of the MSGID is 8 hex digits. As a worst case,
 ml> there are 1096 days in 3 years. (assuming that there's aleap year in
 ml> there somewhere). There are 86400 seconds in a day. That gives 
 ml> 94694400
 ml> seconds. In HEX that's 5A4EC00. Note that this is *7* digits. The max
 ml> number of possible ID's is 100000000h. Doing the division gives 2Dh 
 ml> or
 ml> 45d IDs for each second. I think we can live with a system that's
 ml> limited to tossing messages at 45/second. Or that tosses faster, but
 ml> won't let itself be run again until enough time has passed. 3.9
 ml> *million* messages per day is more traffic than anybody is likely to
 ml> generate!

So if the server is pumping out X amount of messages per user a second,
doesn't that mean that there are X dupes that aren't really dupes based on
the above specs?  Unless you are incrementing the first generated MSGID or
using a DateTime generated by the client's application seeing they probably
can't edit more then one message a second.  However that increases the
amount of input required from the user and then this whole idea of them
using whatever to do Fido starts coming unravelled rather quickly.

 ml> As a *simple* method of doing this, have the program generate the
 ml> Julian Day Number (April 15, AD 1994 is JD#2449457). Then figure 
 ml> modulo
 ml> 2048 of it. That's 49. Shift it to the right an appropriate number of
 ml> bits (multiply by 20 00 00 hex). That gives us 62 00 00 00 hex. And 
 ml> we
 ml> have 20 00 00 hex or 2,097,152 decimal message numbers per day. I 
 ml> think
 ml> that can be handled easily enough. Just generate a message number
 ml> (starting at 0 for the start of the day) and add it to the modified 
 ml> jd.

You've just successfully increased processing time and added an additional
routine as opposed to using the variables you HAVE to carry in order to
generate a pkt with however many messages.  This is what I am attempting to
avoid if possible.

 ml> in pascal, i implemented the above pretty much exactly as show... 
 ml> then someone pointed out that psrt of the above could be switched 
 ml> around to be more linear in the "look"... you'll note
that a serial 
 ml> counter is still used, though ;)

Bah!  Pascal is for wimps!!!  ;-)

Let's see some FORTRAN code.  Heh, heh.

Life is good,
Maurice

--- Msged/LNX 6.1.2