Nп/п : 12 из 100
 От   : Konstantin Kuzov                    2:5019/40         18 авг 24 15:26:52
 К    : Nil A                                                 18 авг 24 15:31:01
 Тема : ru.ftn.develop
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 2:5019/40 66c1e892
@REPLY: 2:5015/46 66c1586f
@PID: GED+LNX 1.1.5-b20231008
@CHRS: CP866 2
@TID: hpt/lnx 1.9.0-cur 2019-01-08
Hello Nil!

18 Авг 24, Nil A wrote to Konstantin Kuzov:

 NA>>>> Hо так никто и не сказал, какой же кашерный алгоритм. А то
 NA>>>> многие от time_t хешь брали.
 SM>>> Hекоторые и сейчас делают sprintf( "%08x", time() ). ;)
 KK>> Ещё помнится sprintf("%08x", ++last_id) было популярно.
 NA> Так делает хаски, и хранит
 NA> # path for current msgid sequence stamp
 NA> # note: this is the name of directory
 NA> SEQDIR          [FidoSysDir]/seq

 Хаски делает как раз-таки от time + тупой sleep(1), а папка с
секвенсами там опциональная фича и является этакой защитой от генерации
одинакового msgid при одномоментнои генераций из разных программ. К примеру когда
ты запускаешь параллельно веер txt2pkt по крону.

Ты можешь сам в этом убедиться почитав genmsgid.c или же эмпирическим путем:
/*=========*/ _copy->paste start_ /*=========*/
 fido@ganjanetwork ~ $ for seq in `find /fido/seqdir/ -printf `%P``;
do s=$(echo $seq | awk -F`.` `{print toupper($1)};`); t=$(echo
"ibase=16;$s" | bc); r=$(date -d @${t}); echo "$seq -> $s -> $t -> $r"; done

66c1e3fa.seq -> 66C1E3FA -> 1723982842 -> Sun 18 Aug 15:07:22 MSK 2024
/*==========*/ _copy->paste end_ /*==========*/

 С обычным же инкрементом надо чтобы ВЕСЬ твой софт, т.е. и редактор
в том числе, использовал единый инкрементор исключающий выдачу одного и
того же идшника при параллельной генерации.

 NA> Synchro чуваку этот вариант тоже не нравится, говорит за 20 лет он
 NA> 2^32 сообщений со своей станции нафигачит.
 NA> У меня ещё вопрос, ведь msgid можно привязать к имя эхи, и тогда точно
 NA> хватит.

 Теоретически можно, но лучше так не делать. Ибо нет никакой гарантии
что разные эхи храняется в обособленных базах, а не скажем в одной
SQL-таблице. Тоже самое касается базы дуполовки. И что при всём многообразии
трекеров, тоссеров, линковщиков и дуполовкок все из них используют в индексах
и логике ещё и поле с именем эхи помимо msgid. Так что практически
увы...

Best of luck, Konstantin.

... GoldED+/LNX 1.1.5 (Linux 6.6.39-1-lts CPU UNKNOWN)
--- #[EMail: Master.NoSFeRaTU[@]Gmail.com] [Kumi Nyaa]#
 * Origin: GaNJaNET STaTi0N (2:5019/40)
SEEN-BY: 50/700 104/117 460/58 256 1124 5858
469/335 4641/222 5001/100
SEEN-BY: 5005/49 5015/46 255 5019/29 40 5020/715
830 848 1042 4441 12000
SEEN-BY: 5023/24 5030/49 1081 5053/58 5054/30
5058/104 5061/133
@PATH: 5019/40 460/58 104/117 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх