Передача большого количества информации

torrent

Большое количество - это очень нечеткое описание. Сколько именно? 1 МБ? 1ТБ? Какой характер имеет эта информация? Хорошо ли сжимается? Имеется ли версионность передаваемой информации?

По-моему ТС довольно четко дал понять, что много информации - значит может не влезть за один проход и его интересуют методы реализации докачки.

Рест для такого использования наверняка не подходит

REST - это принцип построения API. Построй API, который будет поддерживать докачку.

2 сему модератору. с рестом можно что угодно понаписать, хоть докачку, хоть перекачку.

О, спасибо за идею со сжатием инфы! Там json, он должен хорошо паковаться

Инфа - это обновления о продуктах, версионности нет, сейчас шлем всю инфу одним куском, в планах передавать только измененную инфу

По кол-ву я сказать не могу, хз как это посчитать

Оке, что почитать на тему докачки с места обрыва передачи?

хоть тачку с водокачкой :D

А в чём конкретно у тебя проблема? REST тебя не ограничивает в размере ответа, шли хоть терабайтами, лишь бы сериализатор работал без буферизации.

Оке, проблема в том, что обрывается закачка и приходится инфу слать заново сначала

Как как... Выводишь в текстовый файлик и смотришь на размер.

Вот как раз про передачу изменной инфы я и хотел сказать - может и не будет тогда никакой проблемы с докачкой?

Оке, что почитать на тему докачки с места обрыва передачи?

Придумай что-нибудь. Например, разбить посылку на порции, создать на стороне сервера документы /$WHATEVER/unfinished_upload/chunk_XXX, и по HEAD к chunk_XXX выдавать статус загрузки - завершена или нет.

Оке, проблема в том, что обрывается закачка и приходится инфу слать заново сначала

Почему обрывается? Попробуй решить эту проблему. 15 минут это совсем немного, если, конечно, речь не идёт о каких-нибудь мобильных сетях.

Эта обычная проблема при работе с сетью. В самый ненужный момент она умеет обрываться)

Может после сжатия json проблема отпадёт сама собой?))
На тему докачки - сам хз, не сталкивался. Но ты потом расскажи, как решили.
Я бы попытался поделить полученный врхив на части, получать сначала инфу о количестве частей, а уж потом выкачивал по по очереди и собирал обратно в один файл, как это с дискетами делали в своё время))

Пейджинг делай как все делают. Limit + offset

rsync?

Всё это есть в стендарте HTTP. Если сервер поддерживает докачку(и говорит об этом) то клиент может использовать Content-Range https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16

Тебе обязательно http? Может JMS вообще? Почитай enterprise integration patterns чтоли. Тебе claim check подходит, т.е. через БД. Ну или напиши собственный механизм с докачкой и поэтессами. Алсо, rest - скорее архитектура, ты хотел написать «http».

ТС, а вот тебе паттерн интеграции resequencer. Вроде. В общем, почитай, полезно.

Спасибо, почитаю про resequencer. jms неохота просто впиливать

сжать