Извините, что опоздал на щедрую вечеринку с репутацией 500, но даже если я опоздал, я бы хотел добавить немного вашего исследования в ваше обсуждение.
Да, такая система была бы хороша, как Bittorrent , но с зашифрованными файлами и хэшами незашифрованных данных.В BT вы, конечно, можете добавлять зашифрованные файлы, но тогда хэши будут состоять из зашифрованных данных и, следовательно, не смогут идентифицировать поисковые источники без централизованного хранилища queryKey-> hashCollection, то есть сервера, который выполняет всю работу по идентификации package-источники для каждого клиента. Freenet (http://freenetproject.org/),) предприняла попытку подобной системы, хотя и более ограничена, чем вы пытаетесь.
Для рассмотрения NAT давайте сначала рассмотрим: aClient-> yourServer (и aClient-> aClient позже)
Для связи между клиентом и вашим сервером NAT (и брандмауэры, которые защищают клиентов) не являются проблемой! Поскольку клиенты инициируют соединение с вашим сервером(который имеет либо фиксированный IP-адрес, либо DNS-запись (или dyndns)), вам даже не нужно думать о NAT, сервер может ответить без проблем, поскольку, даже если несколько клиентов находятся за одним корпоративным брандмауэром, брандмауэр (егоNAT) будет искать, с каким клиентом сервер хочет установить связь, и переадресовывать соответственно (без необходимости указывать это).
Теперь «сложная» часть: клиент -> клиент связьчерез брандмауэры / NAT: центральная техника, которую вы можете использовать, это пробивание отверстий (http://en.wikipedia.org/wiki/UDP_hole_punching). Это работает так хорошо, это то, что Skype насes (от одного клиента за корпоративным брандмауэром к другому;(если это не удается, он использует зеркальный сервер)).Для этого вам нужно, чтобы оба клиента знали адрес другого, а затем отправляли несколько пакетов друг другу, так как они получают адреса друг друга ?: Ваш сервер выдает адреса клиентам (для этого требуется, чтобы не только запросчик, но и каждый распространитель был открыт).подключение к вашему серверу периодически).
Прежде чем я расскажу о вашей озабоченности по поводу целостности данных, общее различие между пакетов и пакетов вы могли бы (и я думаю,should) make:
Вам просто нужно учитывать, что вы можете разделить ваши пакеты (домен приложения) (большие) и пакеты, используемые для интернет-передачи (маленькие, между прочим ограниченные MTU):будет медленным, чтобы оба были одинакового размера, размер максимального пакета TCP / IP составляет 576 (минус накладные расходы; посмотрите здесь: http://www.comsci.us/datacom/ippacket.html);Вы могли бы провести несколько экспериментов по поводу того, какой размер пакетов будет хорошим, и я думаю, что все 50k-1M были бы хорошими (но профилирование оптимизировало бы это, поскольку мы не делаем, если большинство файлов, которые вы хотите распространять, большие или маленькие),
О целостности данных : для ваших пакетов вам определенно нужен хеш, я бы порекомендовал напрямую взять криптографический хеш , поскольку это предотвращает взлом (в дополнение к повреждению));вам не нужно записывать размер пакетов, так как если хеш-код неисправен, вам все равно придется повторно передавать пакет.Имейте в виду, что такой вид повреждения пакетов встречается не часто, если вы используете TCP / IP для передачи пакетов (да, вы можете использовать TCP / IP даже в вашем сценарии), он автоматически исправляет (повторно-запросы) ошибки передачи.Огромное преимущество заключается в том, что все компьютеры и маршрутизаторы между ними знают TCP / IP и проверяют наличие повреждений автоматически на каждом шаге между исходным и конечным компьютером, поэтому они могут сами повторно запросить пакет, что делает его очень быстро .Они не будут знать о протоколе целостности пакета, который вы реализуете сами, поэтому с этим пользовательским протоколом пакет должен прибыть в пункт назначения, прежде чем повторный запрос может даже начаться.
Для следующей мысли давайте назовем клиента, который публикует файл, "издателем" , я знаю, что это довольно очевидно, однако важно отличать это от "загрузчика", так как клиент делаетне нужно загружать файл на ваш сервер (просто некоторая информация об этом, см. ниже).
Реализация центрального сервера индексации не должна быть проблемой, проблема в том, что вы планируете иметь его зашифруйте все файлы, вместо того, чтобы заставлять издателя выполнять эту тяжелую работу (хорошее шифрование очень тяжело).Единственная проблема с шифрованием данных издателем (а не сервером) заключается в том, что вы должны доверять издателю в предоставлении разумных ключевых слов для поиска: теоретически это может дать вам очень привлекательное ключевое слово для поиска, которое каждый клиент желает, вместе со ссылкой.до фиктивных данных (зашифрованные данные трудно отличить от случайных данных).Но решение этой проблемы - краудсорсинг : сделайте так, чтобы ваш сервер хранил рейтинг пользователей, чтобы загрузчики могли голосовать за файлы.Реализация нужной вам таблицы может представлять собой обычную хеш-таблицу отдельных поисковых ключевых слов для идентификаторов клиентов (см. Ниже), у которых есть этот пакет.Сначала издатель является единственным клиентом, который хранит данные, но каждый клиент, который загрузил хотя бы один из пакетов, затем должен быть добавлен в запись хеш-таблицы, поэтому, если издатель выходит в автономный режим и каждый пакет загружается по крайней мереу одного клиента все продолжает работать.Теперь критически важно, чтобы отображение client-ID-> IP-адреса было нетривиальным, поскольку оно часто меняется (например, каждые 24 часа для многих клиентов);чтобы компенсировать это, у вас должна быть другая таблица на вашем сервере, которая выполняет такое сопоставление и заставляет клиентов периодически (например, каждый час) связываться с сервером, чтобы сообщить ему его IP-адрес.Я бы порекомендовал использовать крипто-хэш для идентификаторов клиентов, чтобы один клиент не мог очистить эту таблицу, сообщив вам поддельные идентификаторы.
По любым вопросам и критике просьба комментировать.