В типичном случае, Клиент через RMI подписывается на события сервера, Сервер, когда ему гонят файло, пробегается по всем подписчикам и отдает кусочки файла через зарегистрированные коллбеки.
Вообще-то задача решается простым паттерном observer, который должен реализовать сервер. Все, кто хочет получать файло, должны зарегистрировать свои коллбеки на сервере, по RMI например, когда клиент А посылает файло серверу, то сервер принимает inputstream, читает его кусочками и пишет эти кусочки всем зарегистрированным коллбекам.
Вот это наборчик, вот это я понимаю хардкор! А сторонними библиотеками пользоваться можно? Если можно, то в apache.commons.io есть класс TeeInputStream и ProxyInputStream commons.apache.org/proper/commons-io/apidocs/org/a...
Это для для двоения потока. Ну а если идем к высоким вещам типа SMTP/POP3, то поможет commons.apache.org/proper/commons-net
Самому реализацией этих вещей на java - мазохизм полнейший! Я уж не говорю про поддержку ssh, здесь вообще труба!
Более того, как появится еще один клиент С, который захочет выборочно смотреть файлы (сообщения) клиента А, то у Вас тут же и получится тот самый велосипед из собственнописанного message broker.
Так а в чем проблема?! Как раз все по TCP и ходит, тот самый мессенджинг и получается :-) Просто не будет RMI, я бы его и так запретил вместе с корбой и rpc, аблолютно нераширяемые штуки, шаг влево - расстрел, весь мир с них сходит постепенно. Или Вам обязательно использовать чистые сокеты? Возьмите реализацию AMQP на java, их есть, например activemq - сам с ним работал в свое время, и энтерпрайзно и явабельно. А так для ознакомления по разным реализациям очередей - queues.io
Если это именно так, то лучше всего обыкновенный sql, например mysql. NoSQL хорош, если у нас неструктурированные данные типа объектов, в Вашем же случае будет только больше накладных расходов.
Если на сервере интернет есть, то проблема настройках клиента, и возможно, в настройках сервера.
1) с клиента должен пиговаться внутренний (к которому подключен клиент) интерфейс сервера
2) с клиента должен пинговаться внешний интерфейс сервера (который смотрит на роутер)
3) с клиента должен пинговаться роутер
4) с клиента должен пинговаться какой нибудь сервер DNS типы 8.8.8.8
да, похоже на правду (про ваш конфиг). только определитесь, куда какой интерфейс смотрит.
самое простое - попинговать IP роутера, клиента и DNS 8.8.8.8 (это DNS от гугла, обычно пингуется).
далее попробовать поработать с DNS командой
host yandex.ru
последняя строчка обычно ненужна (если нет своего DNS), она дает строчку search в файле resolv.conf
как минимум нужно прописать настройки на роутер, его подсеть и где находится DNS. Если роутер пробрасывает DNS, то достаточно указать его IP.
холодная архивация - записал и убрал в коробочку, почти как запись на CD/DVD болванку, при этом автор вопроса предполагает, что будет хранить данные на выделенном для этих целей HDD.
"зачем мне это, мне это не надо." - я же не настаиваю на своем решении, я обрисовал, со своей стороны за и против. vfat вам восстановят практически везде, даже если люди не знакомы с юниксом, tar - сами восстановите. мы же говорим про холодные данные? я, например, до сих пор могу прочитать свои архивы с магнитооптики, сделанные 15-20 лет назад на SCO, HP-UX, OS-9/9000, AIX :-)
"если битый дескриптор будет у файла архива, я потеряю все данные архива?" - и да и нет. Да, файл пропадет. Нет - один боольшой файл легче найти на диске по разрозненным кускам или восстановить его дескриптор, чем от тысяч мелких файлов. Сейчас может быть и не нужны, а завтра?
