@MSGID: 2:6078/1 671135ff
@REPLY: 2:5015/46 670ecafb
@CHRS: CP866 2
@TZUTC: 0200
@TID: hpt/w32-mvcdll 1.4.0-sta 16-02-06
Приветики, Nil!


Писал как-то Nil A к Dmitriy Romanov  примерно 15 Окт 24  в 23:03
А я смотрю и фигею.


 NA>>>>> Несколько раз в год дупы у меня так получаются. Смотрю по
 NA>>>>> логам, и один и тот же бандл пришёл дважды. Так то да, уровень
 NA>>>>> дуполовки отрабатывает, но приходится смотреть почему, чтобы
 NA>>>>> какую-то возможно другую важную причину не пропустить.
 DR>>>> Тогда только один вариант - задержка перед тоссингом. За это
 DR>>>> время должна состояться повторная сессия и бандл скипнется как
 DR>>>> принятый. Если на передающем в него не допакуется что-нибудь
 DR>>>> конечно.
 NA>>> Это может быть как workaround, но не лечение проблемы.
 DR>> А каков должен быть алгоритм корректной работы на твой взгляд?
 NA> Тогда придётся стейт хранить. А это дорого и сложно. Какая-то
 NA> секвенция, порядковый номер бандла, и это всё. А если рассинхрон?
 NA> Проще забить, и пусть уровень выше трахаецо.
 Ну как вариант - на принимающем можно хранить все реквизиты файла -
имя, метка времени, размер, контрольная сумма - и
 проверять при получении при следующей сессии. А на передающей стороне
- если была начата отправка бандла, то он должен
навсегда блокироваться для тоссера для исключения допаковки в него.

      Hа сем разрешите письмо закончить.   Elec (RA2FDR)
--- NoSFeRaTU`s GoldED+/W32-MINGW 1.1.5-b20090603
 * Origin: В свинарнике не стыдно быть свиньей (2:6078/1)
SEEN-BY: 50/109 104/117 221/6 240/1120 301/1 341/66
451/31 452/28 166 455/19
SEEN-BY: 463/68 467/888 478/0 37 4500/1 5000/111
5001/100 5005/33 49 5015/35
SEEN-BY: 5015/42 46 5019/40 400 5020/113 545 620
715 828 830 846 848 1042
SEEN-BY: 5020/1721 2992 4441 12000 5022/128 5030/49
115 1081 1474 5031/71
SEEN-BY: 5049/6 5053/51 55 5054/8 89 5058/104
5060/900 5061/133 5066/18
SEEN-BY: 5068/45 5083/1 444 6078/0 1 2 6090/1
@PATH: 6078/1 5020/830 1042 4441