p2p соединение между двумя клиентами через сервер

Question

Как подключить двух клиентов через сервер и после того, как их сервер подключений отключится? Это означает, что сервер не может получить какие-либо пользовательские данные, а только подключать их. Возможно ли это сделать с помощью java se, или это может быть вообще? Кроме того, клиенты могут находиться в разных локальных сетях, поэтому просто получить адреса клиентов, возможно, не удастся. Если этот метод не является реальным, вы могли бы рекомендовать другой тип безопасного соединения

Answer 1

Есть 3 возможных способов, которыми я могу думать о

: 1: - Сервер IP на основе решение- клиентов знают IP сервера адрес. Сервер прослушивает серверный сокет, а затем клиенты (например, A & B) подключаются через этот серверный сокет и регистрируются сами. Теперь сервер предоставляет IP-адрес клиента A, когда клиент B использует известное имя клиента A, чтобы спросить сервер для IP-адреса клиента A. Клиент A будет прослушивать на сервере Socket - и клиент B подключается к этому сокету. Необходимо соблюдать осторожность, чтобы использовать адресные IP-адреса, то есть общедоступные адреса, такие же маски подсети, обход NAT ...

: 2: - широковещательное/многоадресное IP-решение - все клиенты широковещательные или многоадресные (групповые) - часть широковещания - это хорошо известное имя, таким образом, клиент B будет знать, что такое IP-адрес клиента A. Клиент A будет прослушивать сервер Socket - и клиент B подключается к этому сокету.

: 3: - рассмотреть существующие библиотеки JXTA или TomP2P или Hive2Hive или jnmp2p

Также проверьте этот выход - http://tutorials.jenkov.com/p2p/index.html

Ваши вопросы

Как подключить два клиента через сервер и после того, как их сервер подключений отключится?

: 1 работы - один раз клиент B знает IP-адрес клиента A - сервер можно отключить. Сервер не получает, чтобы увидеть какие-либо данные, которыми обмениваются клиент A и B. Клиент

ли это возможно сделать с помощью Java SE, или это может быть вообще?

да это очень выполнимо - я сделал что-то подобное несколько лет назад в Java - это цифровая камера (Client A) удаленного подключения к устройству хранения (Client B) в домашних условиях. (Я внедрено: 1)

Также клиенты могут быть в разных локальных сетях

да они могут находиться в разных локальных сетях, но они должны быть адресацией. Возьмите то, что я сделал, хранилище, по сути, было внутри домашней сети, а цифровая камера была в общедоступной сети. Вы можете использовать IPv6, или вы можете использовать методы NAT Traversal или Port Forwarding - чтобы сделать клиентов в другой сети видимыми друг для друга. И этот метод очень безопасен.

Для обеспечения безопасности и эффективности вы создадите ключ сеанса (используя Diffie Hellman), и оба клиента будут использовать симметричный шифрование/дешифрование для обмена данными (используя AES).(Вы используете RSA для генерации сеансового ключа - альтернативы Диффи Хеллману. В общем, если вы можете использовать Digital Certificate, используйте RSA - если вы можете использовать общий ключ, используйте Diffie-Hellman)

Если непонятно - объясните свой прецедент более подробно - я могу объяснить ваш случай использования.

Answer 2

Это приложение для android messenger. Вы хотите иметь одноранговое соединение для получения безопасного соединения. Возможно, это возможно с помощью Abhi's answer (first idea), но вам также необходимо выполнить задачу подключения двух устройств.

Другой недостаток сообщения p2p: оба должны быть в сети. если у одного из них есть плохая связь, вы, вероятно, потеряете сообщения или вам будет сложно отправить сообщение.

Даже если у вас есть соединение p2p, вам необходимо зашифровать сообщение, чтобы получить хорошую защиту. Если у вас очень хорошее шифрование, вам, вероятно, не потребуется p2p-соединение [1].

Что вам нужно, это хороший криптографический протокол. Это основная идея:

• Все опубликовали открытый ключ RSA на вашем сервере.
• A хочет поговорить с B, поэтому A шифрует ключ AES A с открытым ключом RSA B.
• B расшифровывает ключ AES A с помощью частного ключа RSA от B.
• (Возможно, B отправляет другой ключ AES в A, но я думаю, что оба могут использовать A A ключ A).
• B подтверждает, отправив сообщение «Hello A», зашифрованное ключом A A.
• Теперь они могут общаться.
• Возможно, стоит заменить ключ AES по истечении заданного времени или после нескольких сообщений чата.

Возможно, вы можете использовать find answers how to do this в переполнении стека (если вы используете его код, пожалуйста, дайте ему верхнюю часть).

Почему вы должны использовать этот сложный протокол вместо простого шифрования всего с помощью RSA? И RSA, и AES - очень сильные криптографические протоколы, но RSA не имеет быстрого вычисления как AES. Вам нужен большой ключ RSA, например, 2048 бит вместо 256-битного ключа AES. Это большой недостаток для мобильных телефонов. Больше расчета означает больший расход энергии. Таким образом, AES работает быстрее, но вы не можете сделать ключевую публикацию. Вместе они очень сильная команда (хотя RSA может разорваться в будущем с квантовыми компьютерами)!

---

[1] Если плохой парень может угнать нормальное соединение клиент-сервер-клиент, он мог бы, вероятно, угнать задачу подключения двух устройств путем создания прокси (человек в центре нападения). И это критическая точка вашего протокола обмена сообщениями, потому что каждый раз, когда кто-то меняет IP (переключение между WiFi и Cellular), вам нужно снова подключиться.