Text 48, 122 rader
Skriven 2005-02-09 10:37:24 av Maurice Kinal (1:153/401.1)
     Kommentar till text 46 av mark lewis (1:3634/12)
Ärende: does anyone really care what time it is?
================================================
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 <patent pending> 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
 * Origin: Coffin Point - Ladysmith, BC Canada (1:153/401.1)