Простая схема:
- Перед загрузкой делаем запрос на сервер, отправляем туда хэш сумму и размер файла (для дальнейшей проверки)
- В ответ получаем идентификатор, с которым будем выполнять загрузку
- Делим файл на желаемое кол-во частей
- Отправляем поочередно полученные части с указанием сдвига и длины "кусочка" файла
- На сервере эти кусочки можно записать во временный файл
- После загрузки всех частей, отправляем на сервер завершающий запрос
- На сервере делаем проверку хэш суммы и размера файла
- В ответ сообщаем о результате загрузки
- Для восстановления процесса загрузки достаточно знать кол-во загруженных частей на текущий момент (узнаем у сервера или сохраняем локально)
- Загрузку можно делать через обычное TCP подключение, в таком случае размер одной части можно сделать очень маленьким (4-8КБ), на каждую отправленную часть сервер должен отвечать пакетом с подтверждением получения.
P.S. Не уверен в эффективности такого решения, но я уже несколько раз применял такую схему в рабочих приложениях.
WebDev, в идеале должна быть таблица с полями user_id, last_message_id (если нужно будет вывести последнее сообщение в списке или другую информацию), last_message_time с уникальным индексом на поле user_id и обычным индексом на поле last_message_time (можно задать сортировку для индекса). Имея такую таблицу, можно максимально быстро сделать описанную в вопросе выборку.
ThunderCat, если поле для сортировки находится в другой таблице, то для получения первых 20-ти записей нужно сначала сделать join, отсортировать и только потом взять первые 20 записей. В такой схеме мы сильно зависим от размера join таблицы. Единственный способ оптимизировать такой запрос - поднять поле для сортировки наверх. Или я что-то не понял?
ThunderCat, чтобы получить 20 последних диалогов, их сначала нужно отсортировать, значит join будет для всех записей. Но даже если выборка будет ограничена, скорость выполнения запроса будет зависеть от этих ограничений.
Мне кажется в этом случае можно вести отдельную таблицу с user_id (uniq index) и временем последнего сообщения. При отправке сообщения выполнять REPLACE по идентификатору пользователя + текущее время.
ThunderCat, про размер таблиц ничего не сказано. В любом случае нежелательно использовать сортировку по полям из другой таблицы. Тем более в данном случае нужно определить дату последнего сообщения для каждого из пользователей.
Вы говорите про перегрузку методов. В Java эта возможность часто используется в качестве альтернативы для параметров по умолчанию. Также это удобно для объявления нескольких методов, выполняющих одно действие, но работающих с разными входными параметрами. По сути это всё делается для удобства.
