Text 15343, 58 rader
Skriven 2011-07-22 10:39:18 av Markus Reschke (2:244/1661)
  Kommentar till text 15338 av Maurice Kinal (1:261/38.9)
Ärende: put your lights on
==========================
Hello Maurice!

Jul 21 14:54 11, Maurice Kinal wrote to Markus Reschke:

 MR>> Changing the signed long into an unsigned long buys 68 years but 
 MR>> breaks a lot of these programs (based on the way they perform time 
 MR>> calculations). They would need to be reworked.

 MK> Hence the suggestion of recycled MSGIDs and not using unixtime to 
 MK> generate them.

I meant the general problem of the time counter overflow. This doesn't matter
the MSGID in any way. When the MSGID overflows due to the unixtime counter
nothing bad would happen. 

 MK> Or not using unixtime to generate ANY id no matter what the bitness.  
 MK> Again a 32 bit id isn't that limiting if recycling is employed.  Only 
 MK> two bytes yeilds a 65,536 unique id block that insures any given user 
 MK> ~60 unique ids per day in a three year cycle which looks to be 
 MK> overkill from what I have seen in any fido echo.

These days for sure :-) 15 years ago it would been a problem for a multiline
BBS.

Using unixtime for MSGID generation is fine. Basically there are two ways to
create unique MSGIDs (or any IDs). One method is using a timestamp like the
seconds counter of unixtime. The problem with that is if you have to create
several IDs at the same time (same second). So the coder needs to add some kind
of ID counter which is added to the timestamp (like msged does). If more IDs
need to be created at one day than a day has seconds we got the next problem.
The next day would have to start in the future regarding the timestamp. In that
case it would be smarter to enlarge the ID to be able to contain a timestamp
and a counter. For current message loads in Fidonet unixtime based MSGIDs are
totally sufficient.

The second method is simply using an ID counter which is increased by each run.
Simple and effective. But the program needs to store the counter in some way on
disk.

There might be some security objections about using a predictable ID. But if
you got the source code of a program using timestamps for ID generation it's
not a lot harder to guess the next ID. No topic for MSGIDs!  

 MR>> And let's not forget about the 
 MR>> gazillions of uCs with clocks. A nightmare :-)

 MK> How many of them are generating MSGIDs?

None, I guess :-) But they all got counters which will overflow some day. Not
all devices are replaced every 6 months like gadgets. People would be
astonished how much 8 bit microcontrollers are still built and used in new
devices. 

Regards,
Markus

--- 
 * Origin: *** theca tabellaria *** (2:244/1661)