Пакет РИБ или обмена БСП на несколько сотен мегабайт уходит на FTP по плохому каналу. На середине связь моргнула, и следующая попытка начинает с нулевого байта. Если канал рвётся раньше, чем пакет успевает дойти целиком, обмен не проходит никогда. А если пакет всё-таки доехал, но с дыркой, это выясняется уже при загрузке, когда администратор смотрит в журнал регистрации и гадает, что сломалось.
На форуме Инфостарта есть ветка https://forum.infostart.ru/forum86/topic336722/ на девять участников, где обсуждают пакеты до гигабайта через FTP. Там же сказано прямо: поддержки докачки нет, при сбое закачка идёт заново.
Я разобрал, что на самом деле делает штатный FTP-транспорт БСП, проверил, умеет ли платформа докачку, и сделал обработку, которая везёт пакет частями, докачивает с первой недоехавшей части и не кладёт пакет в каталог обмена, пока не совпала контрольная сумма. Ниже механика, замеры и три прогона с настоящим обрывом связи.
Стенд: платформа 8.3.27.1606, УТ 11.5 с БСП 3.1.11, локальный FTP-сервер на pyftpdlib, все вызовы 1С через HTTP-сервис базы. Мегабайты в статье двоичные, по 1 048 576 байт.
Что делает штатный FTP-транспорт
Я выгрузил из конфигурации обработку ТранспортСообщенийОбменаFTP и общий модуль ТранспортСообщенийОбмена (БСП 3.1.11, код открыт под лицензией CC BY 4.0) и прочитал отправку и приём. Отправка пакета выглядит так:
// БСП 3.1.11, Обработка.ТранспортСообщенийОбменаFTP, ВыполнитьКопированиеФайлаНаFTPСервер Попытка FTPСоединение.Записать(ИмяФайлаИсточника, КаталогНаСервере + ИмяФайлаПриемника); Исключение СообщениеОбОшибке = НСтр("ru = 'Ошибка подключения к FTP-серверу, ...'"); // ... Возврат Ложь; КонецПопытки;
Один вызов на весь файл, сразу под настоящим именем пакета. Упало - Возврат Ложь, и следующая попытка вызывает то же самое с начала.
Реквизит МаксимальныйДопустимыйРазмерСообщения, на который иногда надеются, пакет не режет. Это ограничение: если файл больше, отправка отказывается с текстом "Превышен допустимый размер сообщения обмена".
Приём берёт из каталога на FTP самый свежий файл, подходящий под шаблон имени. Единственная проверка по дороге такая:
// там же, ПолучитьСообщение ИначеЕсли (ТекущийФайл.Размер() = 0) Тогда Продолжить;
Контрольной суммы нет. Если пакет сжат (флажок сжатия в настройке транспорта), обрезанный архив не распакуется, и это случайная защита. Если не сжат, обрезанный XML уезжает в загрузку как есть.
И есть неприятность, о которой в ветке не пишут. Раз отправка идёт сразу в финальное имя, после обрыва на сервере остаётся огрызок под именем настоящего пакета, и для приёмной стороны он ничем не отличается от целого: ненулевой размер, свежее время изменения. Как это выглядит на деле, ниже.
Докачки в платформе нет, и это проверяется одной строкой
Первая мысль: может, FTPСоединение умеет дописывать или писать со смещения, просто об этом не пишут. Справка по методам Записать и Получить параметров смещения не показывает, но справке по мелочам я не доверяю, поэтому спросил саму платформу:
Попытка Выполнить("С.Записать(Ф, ""/proba2.txt"", 100)"); Исключение // "Слишком много фактических параметров" КонецПопытки;
И Записать, и Получить на 8.3.27 отвечают "Слишком много фактических параметров". Третьего параметра у них нет, дописывать в существующий файл на сервере нечем.
Потом я проверил, что остаётся на сервере после обрыва. Отправил пакет обмена одним Записать, как это делает БСП, и посреди передачи убил процесс FTP-сервера. Платформа ответила исключением Failed sending data to the peer, а на сервере под именем пакета остался файл на 46 % от исходного. Продолжить его нечем, только слать всё заново.
Вторая находка того же прогона пригодится всем, кто пишет свой FTP-обмен. Параметр Таймаут в конструкторе FTPСоединение считается на всю операцию целиком, а не на простой. Я поставил 3 секунды на отправку файла, который на ограниченном канале идёт около десяти: соединение оборвалось ровно на третьей секунде с "Превышен таймаут", хотя данные шли. В штатном транспорте на передачу стоит 12 часов. Если в своём коде вы поставили таймаут минуту "чтобы не висело", большой пакет на медленном канале не уйдёт никогда.
Как докачивать, если платформа не умеет
Раз писать со смещения нельзя, единица докачки это файл. Пакет режется на части, каждая часть уходит отдельным файлом. Часть либо доехала целиком, либо шлётся заново, и после обрыва теряется максимум одна часть.
Главный вопрос, по какому признаку считать часть доехавшей. Одного размера файла на сервере мало: огрызок тоже имеет размер. Поэтому каждая часть пишется во временное имя и переименовывается в финальное только после того, как Записать вернулась без ошибки. Финальное имя появляется на сервере, только когда данные уже записаны целиком:
ИмяВременного = ПолучитьИмяВременногоФайла("part"); Данные.Записать(ИмяВременного); ПутьЧасти = ПутьНаСервере(Пакет.УдалённыйКаталог, ИмяЧасти(Номер)); Попытка Соединение.Записать(ИмяВременного, ПутьЧасти + ".tmp"); Исключение УдалитьФайлы(ИмяВременного); ВызватьИсключение; КонецПопытки; УдалитьФайлы(ИмяВременного); Соединение.Переместить(ПутьЧасти + ".tmp", ПутьЧасти);
Если связь упала между записью и переименованием, на сервере останется только .tmp, и часть при следующей попытке уйдёт заново: потеря та же, одна часть.
Часть вырезается из пакета на лету файловым потоком, без предварительной нарезки всего файла. У платформы есть РазделитьФайл, и работает она быстро, но она кладёт рядом вторую копию пакета, а отправителю эта копия не нужна вовсе:
Поток = ФайловыеПотоки.ОткрытьДляЧтения(ПолноеИмя); Поток.Перейти(Смещение, ПозицияВПотоке.Начало); Буфер = Новый БуферДвоичныхДанных(Длина); Прочитано = Поток.Прочитать(Буфер, 0, Длина); Поток.Закрыть(); Данные = ПолучитьДвоичныеДанныеИзБуфераДвоичныхДанных(Буфер);
На FTP для каждого пакета появляется своя папка:
/obmen/Message_A_B.xml.parts/opis.txt размер, SHA-256 пакета и каждой части (уходит первой) /obmen/Message_A_B.xml.parts/0001.part части; пишутся в NNNN.part.tmp, потом переименовываются /obmen/Message_A_B.xml.parts/gotovo.txt SHA-256 пакета (уходит последним)
Опись уходит первой, файл готовности последним. Пока его нет, приёмная сторона пакет не трогает и пишет "отправитель ещё не закончил: на сервере столько-то частей из стольких". После обрыва отправитель читает опись на сервере, видит, что она от того же пакета (тот же SHA-256), и шлёт только части, у которых нет файла с финальным именем и нужным размером. Если под тем же именем лежит опись другого пакета, значит обмен успел выгрузить новый, и старые части удаляются.
Хеш пакета считается один раз за проход по файлу вместе с хешами частей, объектом ХешированиеДанных. SHA-256 пакета в 600 МБ через ДобавитьФайл считается около пяти секунд, и результат я сверил с независимым hashlib из Python: совпал до символа. CRC32 (32-битная контрольная сумма) быстрее втрое, но 32 бита на файл в сотни мегабайт мне мало.
Сколько весит одна часть
Каждая часть стоит нескольких обменов командами с сервером: соединение, вход, пассивный канал, переименование. На петле 127.0.0.1, то есть внутри одной машины, я намерил около 25 мс на часть при любом её размере. Это нижняя граница. На живом канале каждая команда ждёт ответа сервера, и если пинг туда и обратно 150 мс, то 6-7 таких обменов дают около секунды на часть. Это оценка, на живом канале я её не мерил.
Мелкие части съедают время на накладных, крупные дорого терять при обрыве: в среднем теряется половина части. Если сложить обе потери и найти минимум, выходит оптимальный размер части = корень(2 x размер пакета x накладные на часть x скорость канала / число обрывов). Для пакета в гигабайт, секунды накладных и пяти обрывов это около 7 МБ на канале 1 Мбит/с и около 23 МБ на 10 Мбит/с. Плохой канал обычно и медленный, поэтому я взял 8 МБ. На 1 Мбит/с такая часть уходит за минуту с небольшим, это худшее, что теряется при обрыве.
Размер части в настройки не вынесен: он пишется в опись, и приёмная сторона берёт его оттуда. У этого решения есть нижняя граница. Таймаут одной операции в обработке 10 минут, значит на канале медленнее 14 КБ/с часть в 8 МБ не пройдёт за одну операцию никогда. Для такого канала нужен меньший размер части, и это первое, что я вынесу в настройку, если такой случай найдётся.
Приём: хеш до загрузки
Получатель качает части по описи в рабочую папку внутри каталога обмена и у каждой сверяет SHA-256. Не совпало - качает ту же часть второй раз. Совпало со второго раза, значит в первый раз сбоила сеть. Не совпало и во второй раз - часть испорчена на сервере:
Совпал = Ложь; Для Заход = 1 По 2 Цикл УдалитьФайлы(ИмяВременного); Соединение.Получить(ПутьЧасти, ИмяВременного); Если ХешФайла(ИмяВременного) = Ожидаемый Тогда Совпал = Истина; Прервать; КонецЕсли; КонецЦикла; Если Не Совпал Тогда // битую часть убираем с сервера вместе с отметкой готовности: // следующая отправка дошлёт только её УдалитьНаСервере(Соединение, ПутьЧасти); УдалитьНаСервере(Соединение, ПутьНаСервере(Пакет.УдалённыйКаталог, "gotovo.txt")); КонецЕсли;
Когда все части на месте, они склеиваются ОбъединитьФайлы, у собранного файла ещё раз считается SHA-256, и только при совпадении пакет переносится в каталог обмена. Рабочая папка лежит внутри каталога обмена, а транспорт "каталог" ищет пакет только в самой папке, без подпапок: у него НайтиФайлы(КаталогОбменаИнформацией, ШаблонИмениСообщения, Ложь). Поэтому части и полусобранный файл загрузка не видит, а перенос готового пакета это переименование в пределах одного диска. На время сборки у получателя лежат и части, и собранный файл, то есть нужно около двух размеров пакета. После переноса части удаляются.
Как это встраивается в обмен
Свой транспорт в БСП 3.1.11 подключается только через конфигурацию: список транспортов собран в общем модуле ТранспортСообщенийОбмена одиннадцатью строками плюс переопределяемая процедура. Править конфигурацию ради доставки файла не хочется, поэтому обработка встаёт мостом между двумя каталогами. В узле ставится штатный транспорт "Локальный или сетевой каталог". На стороне отправителя обработка забирает пакет из этого каталога и везёт на FTP. На стороне получателя забирает с FTP и кладёт в такой же каталог, откуда пакет берёт штатная загрузка. От версии БСП это почти не зависит: важны только папка и имя файла.
Транспорт "каталог" пишет и читает в одной папке, поэтому свой исходящий пакет от входящего обработка отличает по имени. БСП называет пакет Message_<отправитель>_<получатель>. Если мы узел А, исходящий пакет называется Message_А_Б, входящий Message_Б_А: входящий кончается нашим кодом, у исходящего наш код стоит первым (бывает, что перед ним ещё префикс базы). Код обработка берёт из ЭтотУзел() планов обмена сама, в форме его можно перебить.
Для работы по расписанию у обработки есть серверная команда дополнительной обработки БСП "Отправить и получить пакеты обмена через FTP": сначала отправляет исходящие, потом забирает входящие. Вызовом из кода я её прогнал в обе стороны. Через регистрацию в справочнике дополнительных обработок с расписанием не гонял, это следующий шаг.
Старые конфигурации и двойной запуск
Главные потребители FTP-обмена это часто не свежие релизы, а конфигурации, которые годами не обновляли. Платформа там может быть свежей, а конфигурация стоит в режиме совместимости 8.2.16, и в этом режиме платформа закрывает всё, что появилось в 8.3.6: СтрНайти с направлением поиска, СтрРазделить, СтрСоединить, СтрЗаканчиваетсяНа и перечисление НаправлениеПоиска. Первая сборка обработки ими пользовалась и в такой базе даже не создавалась:
Ошибка инициализации модуля: ВнешняяОбработка.FTPДокачкаПакетовОбмена.МодульОбъекта
{...МодульОбъекта(213,34)}: Переменная не определена (НаправлениеПоиска)
Интересно, что проверка модулей конфигуратором (/CheckModules) в той же базе этого не видит и отвечает "Синтаксических ошибок не обнаружено", а ловит только создание обработки. Я заменил эти функции своими на Найти, Лев и Сред, например поиск последнего вхождения:
Функция ПозицияПоследнего(Знач Строка1, Знач Подстрока) Итог = 0; Позиция = Найти(Строка1, Подстрока); Сдвиг = 0; Пока Позиция > 0 Цикл Итог = Сдвиг + Позиция; Сдвиг = Итог + СтрДлина(Подстрока) - 1; Позиция = Найти(Сред(Строка1, Сдвиг + 1), Подстрока); КонецЦикла; Возврат Итог; КонецФункции
и проверил внешним соединением во временных базах с режимами совместимости 8.2.16, 8.3.5 и 8.3.10: обработка создаётся, полная отправка и приём пакета проходят, SHA-256 доставленного пакета совпадает. Сборка до правки в тех же базах при 8.2.16 и 8.3.5 падает с ошибкой выше, так что проверка не холостая. Платформа при этом нужна от 8.3.20.
Второй житейский случай: отправка стоит по расписанию, а администратор жмёт кнопку вручную, потому что "что-то долго". Два запуска по одному каталогу слали бы одни и те же части. Поэтому в рабочей папке внутри каталога обмена лежит файл-замок, свой для отправки и для приёма, и каждый шаг передачи обновляет в нём время. Вторая копия видит свежий замок и отвечает "Уже идёт отправка из этого каталога обмена другим запуском обработки", ничего не трогая. Замок, который не обновлялся 15 минут, считается брошенным: это форма, закрытая посреди передачи, и следующий запуск его перехватывает и продолжает с первой недоехавшей части. 15 минут взяты с запасом больше таймаута одной FTP-операции, чтобы медленная часть не приняла свой же замок за брошенный.
Три прогона с настоящим обрывом
Пакет для прогонов настоящий: сообщение обмена, выгруженное платформенной ЗаписьСообщенияОбмена по служебному плану обмена БСП "ОбменСообщениями" (на стенде он только даёт узлы отправителя и получателя). Внутри около 60 тысяч элементов справочника "Номенклатура", 632 988 913 байт без сжатия, то есть 603,7 МБ и 76 частей: 75 по 8 МБ и последняя на 3,7 МБ. Обрыв я делал убийством процесса FTP-сервера посреди передачи, канал ограничивал до 4 МБ/с, чтобы попадать в середину части, а не между частями.
Прогон 1, обрыв и докачка. Отправка оборвалась на 16-й части из 76: к этому моменту на сервере лежали 15 частей с финальными именами (120 МБ за 32 секунды) и недописанный 0016.part.tmp. Платформа ответила Failure when receiving data from the peer. Текст другой, чем в прогоне выше, но это тот же обрыв: сервер пропал посреди передачи. После перезапуска сервера вторая попытка прочитала опись, увидела те же 15 частей и довезла остальные 61 (483,7 МБ за 2 минуты 7 секунд). Повторно не ушло ни одной части: 15 и 61 дают ровно 76. Без докачки вторая попытка повезла бы все 603,7 МБ, то есть ещё раз те же 120 МБ. На этом канале целый пакет идёт около двух с половиной минут, и при обрывах каждые полминуты он не дошёл бы никогда. Потом я так же оборвал приём: на 20-й части, когда в рабочей папке получателя лежали 19 проверенных частей. В каталоге обмена пакета при этом не было. Вторая попытка приёма скачала оставшиеся 57.
Прогон 2, порча части. Чистая отправка, затем прямо в папке FTP-сервера в части 0040 я заменил 16 байт в середине, размер файла не изменился. Получатель скачал 39 частей, на сороковой хеш не совпал дважды, и обработка вернула итог с видом "ошибка" (в форме он красный): "Пакет НЕ положен в каталог обмена: ... часть 40 из 76 битая на сервере". Каталог обмена остался пустым, на FTP осталось 75 частей без файла готовности. Следующая отправка досылала ровно одну часть, 8 МБ за доли секунды, а второй приём скачал только части с 40-й по 76-ю и положил пакет с совпавшим хешем. В журнале это видно строкой "Повторно отправлено частей: 1": та самая испорченная часть ушла дважды.
Прогон 3, чистая передача и загрузка. Без обрывов и без ограничения канала пакет ушёл за 7 секунд и пришёл за 12 (это петля 127.0.0.1, на живом канале время определит скорость). Доставленный пакет я загрузил платформенными объектами обмена в узле-получателе: ЧтениеСообщенияОбмена приняло заголовок (отправитель, получатель, номер сообщения), дальше каждый объект читался ПрочитатьXML и записывался с ОбменДанными.Загрузка = Истина, так, как пишет объекты РИБ. Прочитаны и записаны все объекты пакета, ошибок ноль, номер принятого сообщения у узла-отправителя стал равен номеру пакета. Полноценный узел синхронизации БСП между двумя базами я не настраивал, поэтому скажу точно: пакет, доставленный обработкой, платформа прочитала как сообщение обмена и записала целиком.
SHA-256 я сверял независимо от 1С, штатным crypto из Node.js. В прогонах 1 и 3 на трёх сторонах: пакет на узле-отправителе, склейка частей прямо в папке FTP-сервера и пакет, положенный в каталог получателя. Во втором на двух, у отправителя и получателя: получатель после приёма убирает папку пакета с FTP.
Что видно в обработке
Сверху крупная строка итога, окрашенная по результату: идёт, доставлено с совпавшим хешем, обрыв с номером части, с которой продолжим, или отказ класть пакет в каталог с причиной. Под ней таблица пакетов с цветным статусом. Журнал хранит по каждому пакету все попытки и отдельной строкой число частей, ушедших повторно, а кнопка выгрузки в Markdown собирает журнал и диагноз обрывов в один файл для нейросети или админа канала, без логина и пароля FTP.
Частые вопросы
Почему не докачка с того байта, где оборвалось? У FTPСоединение нет записи со смещения, это проверено вызовом. Можно было бы уйти во внешнюю утилиту, но тогда это уже не обработка 1С и нужна установка на каждом сервере.
Чем это лучше включённого сжатия в штатном транспорте? Сжатие даёт случайную защиту от обрезанного пакета: битый архив не распакуется. Но пакет по-прежнему уходит целиком, после обрыва с нуля, и огрызок лежит на сервере под настоящим именем.
Что будет с пакетом, который обмен перевыгрузил, пока старый ехал? Каждую часть перед отправкой отправитель сверяет с описью по хешу, а перед финальной отметкой сверяет размер и время изменения файла. Файл поменялся - попытка закрывается с пометкой "пакет изменился", следующая отправка видит на сервере опись другого пакета, удаляет старые части и везёт новый.
Заработает ли в конфигурации с режимом совместимости 8.2? Да, проверено при режимах 8.2.16, 8.3.5 и 8.3.10, см. раздел выше. Сама платформа нужна от 8.3.20.
Что будет, если запустить отправку дважды? Вторая копия ответит "уже идёт" и ничего не тронет, замок описан выше.
Что с FTPS (FTP с шифрованием TLS)? У FTPСоединение есть параметр защищённого соединения, и в коде он используется для адреса ftps://. На моём стенде с TLS передача зависала на листинге каталога, поэтому FTPS я не заявляю, пока не проверю на живом сервере.
Где взять
Обработка "FTP с докачкой для пакетов обмена" на Инфостарте: //infostart.ru/1c/tools/2804240/.
Другие наши инструменты
- Анализ правил обмена КД 2
- Чек-ап сервера 1С: настройки кластера и рабочих процессов
- Анализ нагрузки кластера 1С: кто блокировал базу, кто грузил сервер
- Чек-ап СУБД под 1С
Кто-нибудь ловил у себя огрызок пакета, который приёмная сторона взяла с FTP как целый? Интересно, чем это кончилось на загрузке и сколько времени ушло понять, что дело в транспорте.
Вступайте в нашу телеграмм-группу Инфостарт