Обработка на Инфостарте
Обмен через FTP с докачкой: пакет продолжает с места обрыва
Филиал на слабом канале, пакет обмена на несколько сотен мегабайт, связь рвётся каждые полчаса. Штатный FTP-транспорт каждый раз начинает с нулевого байта, и обмен не доходит никогда. Обработка режет пакет на части, после обрыва досылает только недоехавшие и не пускает пакет в загрузку, пока не сошлась контрольная сумма.
Обработка продаётся на Инфостарте за 10 SM, код открыт. Внешняя обработка на управляемых формах, конфигурацию не меняет. Проверена на платформе 8.3.27 и УТ 11.5 с БСП 3.1.11.
Мы разобрали код FTP-транспорта БСП 3.1.11 и нашли две вещи. Первая: пакет уходит на сервер одним вызовом, сразу под своим настоящим именем. Если связь оборвалась на середине, на FTP остаётся обрезанный файл с правильным именем, и приёмная сторона забирает его как целый, потому что ищет самый свежий файл ненулевого размера. Контрольную сумму транспорт не проверяет, и обрыв всплывает уже ошибкой разбора при загрузке.
Вторая: докачку со смещения средствами платформы не сделать. У объекта FTPСоединение методы Записать и Получить принимают ровно два параметра, на третий платформа отвечает "Слишком много фактических параметров". Значит, единицей докачки может быть только отдельный файл, и обработка так и устроена: пакет едет частями по 8 МБ, каждая часть сначала пишется во временное имя и получает финальное только после полной записи.
Сам обмен обработка не трогает. Выгружает и загружает пакет штатный механизм через транспорт "Локальный или сетевой каталог", а обработка стоит между этим каталогом и FTP-сервером и только перевозит файл. Конфигурацию править не нужно, от версии БСП зависит мало: важны папка и имя пакета.
Как устроена доставка
Опись едет первой
В опись пишутся размер пакета, SHA-256 пакета и каждой части. Файл готовности уходит последним. Пока его нет, получатель только сообщает, сколько частей уже лежит на сервере, и пакет не забирает.
Доехавшая часть видна по имени
Файл NNNN.part появляется на сервере только после того, как Записать вернулась без ошибки. Обрыв между записью и переименованием оставляет .tmp, и такая часть просто уйдёт ещё раз.
Хеш сверяется до загрузки
Получатель проверяет SHA-256 каждой части и собранного пакета. Часть, битая на сервере, удаляется с FTP вместе с отметкой готовности, следующая отправка досылает только её.
Перевыгруженный пакет не смешивается со старым
Если обмен успел выгрузить новый пакет, пока ехал прежний, отправитель видит это по описи, размеру и времени изменения файла, удаляет старые части и везёт новый пакет.
Два запуска не мешают друг другу
Ручной запуск поверх регламентного видит свежий замок и выходит, ничего не трогая. Замок, который 15 минут не обновлялся, считается брошенным, и передача продолжается с той же части.
Журнал и выгрузка для нейросети
По каждому пакету все попытки, место обрыва и число частей, ушедших повторно. Выгрузка в Markdown собирает это в один файл без логина и пароля FTP.
Что на FTP-сервере во время передачи
Пакет лежит в папке со своим именем, рядом с каталогом обмена на FTP. Транспорт "каталог" на стороне получателя подпапки не смотрит, поэтому части и полусобранный файл загрузка не увидит.
| Файл | Зачем он |
|---|---|
| opis.txt | Размер пакета, SHA-256 пакета и всех частей. По нему отправитель после обрыва понимает, что на сервере лежат части того же пакета, а получатель знает, что качать и с чем сверять. |
| 0001.part ... NNNN.part | Части, доехавшие целиком. Наличие файла с финальным именем и нужным размером и есть отметка "часть доставлена". |
| NNNN.part.tmp | Часть, которая пишется прямо сейчас или оборвалась. После обрыва уходит заново, теряется не больше одной части. |
| Отметка готовности | Появляется последней, когда все части на месте. До неё получатель пакет не забирает. |
Три прогона с настоящим обрывом
Управление торговлей 11.5.22, БСП 3.1.11, платформа 8.3.27, локальный FTP-сервер. Настоящий пакет обмена 603,7 МБ, 76 частей. Обрыв делали убийством процесса FTP-сервера посреди передачи, канал ограничивали до 4 МБ/с. SHA-256 сверяли отдельно от 1С, средствами Node.js.
| Показатель | Значение | Как надо | Вердикт | Что это значит |
|---|---|---|---|---|
| Обрыв отправки на 16-й части | повторно 0 частей | 0 | норма | до обрыва ушло 15 частей, 120 МБ за 32 с; вторая попытка довезла остальные 61 часть, 483,7 МБ за 2 мин 7 с |
| Обрыв приёма на 20-й части | докачано 57 частей | только недостающие | норма | 19 проверенных частей лежали в рабочей папке, в каталоге обмена пакета не было до конца приёма |
| Часть 40 испорчена на сервере (16 байт, размер тот же) | пакет не положен | не положен | норма | хеш не сошёлся дважды, каталог обмена остался пустым; отправитель дослал одну часть, в журнале "Повторно отправлено частей: 1" |
| Чистая передача без ограничения канала | 7 с отправка, 12 с приём | - | инфо | петля внутри одной машины; на живом канале время определит скорость |
| Загрузка доставленного пакета | 0 ошибок | 0 | норма | прочитан платформенными объектами обмена и записан целиком, номер принятого сообщения у узла совпал с номером пакета |
| Режимы совместимости 8.2.16, 8.3.5, 8.3.10 | отправка и приём проходят | проходят | норма | SHA-256 доставленного пакета совпал; платформа нужна от 8.3.20 |
| Запуск по расписанию | проверен вызовом команды | - | внимание | команда "Отправить и получить" прогнана из кода в обе стороны; через справочник дополнительных обработок с расписанием не гоняли |
| FTPS | не заявляется | - | внимание | на стенде с TLS передача зависала на листинге каталога; SFTP обработка не умеет |
Разбор результата
Главное число первого прогона: ни одна часть не ушла дважды. Без докачки вторая попытка повезла бы все 603,7 МБ заново, а на этом канале целый пакет идёт около двух с половиной минут. При обрывах каждые полминуты такой пакет штатным транспортом не дошёл бы ни разу.
Как подключить к обмену
- 01
Переключить узел на каталог
В настройке синхронизации выбрать транспорт "Локальный или сетевой каталог" и указать каталог на сервере 1С. То же сделать на второй стороне. У учётки службы 1С должны быть права на запись в этот каталог.
- 02
Заполнить FTP в обработке
Адрес вида ftp://сервер:21/obmen (каталог на FTP общий для обоих узлов), пользователь, пароль, пассивный режим и тот же каталог обмена, что в узле. Логин и пароль прямо в адресе обработка не примет.
- 03
Отправить и получить
Отправитель после выгрузки нажимает "Отправить пакет", получатель "Получить пакет", дальше пакет загружает штатный обмен.
- 04
Поставить на расписание
Зарегистрировать файл в "Дополнительных отчётах и обработках" (нужна БСП) и включить расписание у команды "Отправить и получить пакеты обмена через FTP". Обрыв при регламентном запуске пишется в журнал, следующий запуск продолжит с той же части.
Не получается самим? Напишите, разберёмся
Связываем 1С с чем угодно: другими базами 1С, сайтами, CRM, банками, госсистемами. Чиним обмены, которые "отваливаются" и копят очереди.
- Стоимость
- 450 000 - 600 000 ₸ТЗ и диагностика, без налогов; типовая задача закрывается в тот же срок, подсистема "ОбменПоHTTP" под ключ - по смете единым счётом
Рядом по теме
Регистрация изменений в плане обмена 1С
Что происходит до того, как пакет вообще выгрузится: пять ступеней между записью объекта и строкой в таблице изменений узла.
Анализ правил обмена КД 2
Если обмен идёт по правилам Конвертации данных: что выгружается, как объект ищется в приёмнике и где лежит код.
Таймаут обмена 1С с внешним сервисом
Та же ловушка таймаутов с другой стороны: как отличить занятый сервис от лежащего и почему повтор без проверки плодит дубли.
Частые вопросы
Почему части, а не докачка с того байта, где оборвалось?
Платформа не умеет писать на FTP со смещения: у FTPСоединение нет такого параметра, это проверено вызовом. Внешняя утилита это умеет, но тогда нужна установка на каждый сервер, и это уже не обработка 1С. Часть в 8 МБ на канале 1 Мбит/с идёт минуту с небольшим, это худшее, что теряется при обрыве.
Почему именно 8 МБ?
Мелкая часть съедает время на служебных командах FTP, крупную дорого терять при обрыве. Если сложить обе потери, для пакета в гигабайт и пяти обрывов оптимум выходит около 7 МБ на канале 1 Мбит/с и около 23 МБ на 10 Мбит/с. Плохой канал обычно и медленный, поэтому взяли 8. Размер пишется в опись, получатель берёт его оттуда.
Какой канал обработка не протащит?
Медленнее примерно 14 КБ/с. Таймаут одной FTP-операции в обработке 10 минут, а платформа отсчитывает таймаут от начала операции, даже когда данные идут без остановки. На стенде таймаут в 3 секунды оборвал передачу ровно на третьей секунде, хотя данные шли. Если в своём коде вы ставили таймаут в минуту, большой пакет на медленном канале не уйдёт.
Включённое сжатие в штатном транспорте не спасает?
Частично. Обрезанный архив не распакуется, и битый пакет не загрузится. Но после обрыва пакет всё равно уходит целиком с начала, а обрезанный файл лежит на сервере под настоящим именем.
Где хранится пароль FTP?
В общих настройках базы, так же как настройки отчётов. В журнал, итог и выгрузку для нейросети логин и пароль не попадают.
Сколько места нужно у получателя?
Около двух размеров пакета: на время сборки лежат и части, и собранный файл. После переноса пакета в каталог обмена части удаляются.
Бесплатный экспресс-аудит вашей 1С
За 1-2 дня посмотрим вашу базу, найдём, где теряется производительность, и скажем, что с этим делать. Без обязательств.
Обсудим задачу
Быстрее всего в WhatsApp: напишите пару строк о задаче, ответим в течение рабочего дня.