Создал хранилище данных в одном зашифрованном файле

[Metotron0]

Про отключение света не понял. Что, если его отключат, когда временный файл будет копироваться в основной файл?

[piterovxyz]

тогда хранилище при повторном запуске сделает truncate, т.е. отрежет битые данные. по сути придется залить снова

[Metotron0]

Но ведь можно было сделать это и при записи сразу в нужный файл.

[Patrick139]

дайте человеку поизобретать велосипед.

[mantyr]

Привет. Интересный концепт. Очень полезное такое делать. Но... есть небольшая проблема.

gRPC очень медленный для передачи файлов.

Маленькие чанки -> оооочень медленно.
Ограничение в 40 мегабайт на запрос выглядит хорошо, но... тоже медленно.

Проблема в миксере трафика в канале. Даже когда вы отправляете запросы от одного клиента в один поток - на деле это куча маленьких чанков внутри.

Даже если вы сделали мега-большие запросы (десятки мегабайт) они всё равно внутри бьются на небольшие...

Увеличенные лимиты на клиенте и сервере эту задачу тоже не решают.

Решение: передавать по gRPC только мета-информацию, а для файлов открывать отдельные соединения.

[piterovxyz]

Привет! Спасибо, посмотрю, как можно сделать ещё. А по какому протоколу вы бы могли лучше всего посоветовать передавать большие данные?

[mantyr]

Попробуйте https причём обычный, а не 2.0 и не quic.

Вы будете смеяться но под капотом gRPC лежит http 2. Хотя вы можете поизучать вопрос более детально и поискать в протоколе http 2 информацию о том есть ли там что-то для отключения миксера для передачи файлов.

Обычный же https на http 1.1 даст и шифрование трафика и tcp поток после передачи заголовков (если интересно посмотрите как делается переход с http на websocket и другие протоколы поверх открытого порта через http) и собственно удобство заголовков как таковых.

На стороне сервера создаёте JWT токен, подписываете и передаёте его клиенту. Клиент подключается по https, передаёт JWT в заголовке (изучите какие заголовки для этого бывают), а сервер принимает файл после того как обработает JWT.

JWT в данном случае может быть двух видов:
- с данными куда и что положить, то есть прямое указание к действию, тогда база данных для задачи не нужна, тут нужна дата внутри токена и дата экспирации.

- максимально компактный (uid пользователя или uid задачи и например для чего этот токен + подпись), тогда по идентификатору можно вытащить всё необходимое из базы. Тут даже даты может не быть, но с датой можно сразу не ходить в базу данных.

Дальше вопрос как передавать файлы по http... путей два:) Обычными файлами как это делают браузеры или самописный вариант на основе открытого порта (перевести его в "другой" режим, например бинарный)

Ещё можно перевести запрос в обратную сторону, что бы сервер стал вытягивать данные с клиента.

Токен тоже не обязательно должен быть JWT. Можно простую строку подписать в формате: {request_id}.{sign}, многие сессии в браузере выглядят похожим образом. Но часто там что-то вроде base64({user_id}.{timestamp}.{sign})

Вы так же можете выбрать чистый TCP но это потребует решения дополнительных задач.