Subj : does anyone really care what time it is? To : mark lewis From : Maurice Kinal Date : Wed Feb 09 2005 10:37 am 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 * Origin: Coffin Point - Ladysmith, BC Canada (1:153/401.1) .