Вообще-то задача решается простым паттерном 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 :-)
"если битый дескриптор будет у файла архива, я потеряю все данные архива?" - и да и нет. Да, файл пропадет. Нет - один боольшой файл легче найти на диске по разрозненным кускам или восстановить его дескриптор, чем от тысяч мелких файлов. Сейчас может быть и не нужны, а завтра?
за tar: 1) старый добрый формат, ориентированный на потоковое хранение (лента), если есть битый кусок, то tar его пропускает и пытается восстановить небитые куски файлов. 2) tar сохраняет все исходные атрибуты файла (даже расширенные) 3) tar есть на любом юниксе из коробки, куча реализаций в винде, все его читают и понимают. Почему не хранить в отдельных файлах: 1) файл занимает не только место на диске, но и занимает место в дескрипторе файловой системе 2) при переписи файла с одной ФС на другую скорее всего потеряются многие атрибуты файла, начиная от пользователя и заканчивая расширенными 3) битый дескриптор - отсутсвие файла, независимо от его размера, а в случае с архиватором, мы восстановим хотя бы кусок! Почему на rar, 7zip, прочая проприетарщина и сжатие: 1) что будет с совместимостью лет через 5-7, сможем прочитать старую версию архива? Сможем запустить старый архиватор в новейшей виндовс севентин? 2) сжатие, при порче хотя бы бита архива, весь его можно выкинуть - не восстановить. 3) опять же атрибуты файлов - они пропали!
Надеюсь, поможет.