LINUX.ORG.RU

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

 , ,


0

2

Предположим, нам надо передать большое кол-во инфы в джавке. Сейчас рест запрос длится около минут 15-20. Надо добавить механизм возобновления передачи инфы с последней переданной позиции или многотредовой передачи информации(но это гемор, кмк). Рест для такого использования наверняка не подходит. Что можно заюзать, о каких протоколах почитать?

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

TheKnight ★★ ()
Ответ на: комментарий от TheKnight

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

bdfy ★★★★★ ()

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

anonymous ()
Ответ на: комментарий от TheKnight

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

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

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

by_zero ()
Ответ на: комментарий от tailgunner

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

by_zero ()

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

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

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

by_zero ()
Ответ на: комментарий от by_zero

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

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

TheKnight ★★ ()
Ответ на: комментарий от by_zero

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от by_zero

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

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

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

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

ii8_ ★★★★ ()
Ответ на: комментарий от by_zero

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

ii8_ ★★★★ ()

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

Kartas39 ()

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

bytecode ★★ ()
Ответ на: комментарий от ii8_

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

bytecode ★★ ()
Ответ на: комментарий от bytecode

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

by_zero ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.