| Версия для печати
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум на Исходниках.RU > C/C++: Сетевое программирование > Реализация p2p |
| Автор: ter_nk_ 12.07.16, 18:13 |
| Чтобы организовать соединение между например мобильным устройством и компьютером должен быть сервер с IP, отправляем ему по UDP что я такой-то. В локалке он один, сервер видит его другим, другое устройство так же посылает пакет, сервер видит его уже другим. Сервер может одному устройству послать внешний айпишник и порт другого, но оба то одновременно в сети они не видны. Как то я тут немного запутался, просветите. Есть еще так понимаю для этого STUN сервера. |
| Автор: simsergey 12.07.16, 18:30 |
| Стоит сформулировать вопрос. Мало что понятно из приведенного выше.. |
| Автор: ter_nk_ 12.07.16, 18:45 |
| p2p как лучше реализовать, собственно пока теоретически. |
| Автор: Oleg2004 12.07.16, 20:01 |
| А погуглить? |
| Автор: ter_nk_ 13.07.16, 03:22 |
| Нагуглил snupserver, у меня вопрос теоретический пока, как лучше сделать, а не как вообще сделать, реализовать как-нибудь я могу. |
| Автор: Pacific 13.07.16, 07:18 |
| ter_nk_ - Клиент 1 шлет UDP пакет серверу на его server_ip:port - Клиент 2 шлет UDP пакет серверу на тот же server_ip:port - Сервер запоминает client1_ip:port и client2_ip:port (такими, какими их видит сервер, то есть их внешние IP:port) - Цикл повторяется На второй итерации цикла сервер уже знает оба внешних клиентских IP:port и отсылает их в ответ клиентам, после чего те могут слать данные друг другу, используя client1_ip:port и client2_ip:port Работает не на всех типах NAT, а только на тех, где NAT использует фиксированный маппинг (внутренний IP:port -> внешний номер порта) независимо от того, на какой IP:port идет пакет наружу. В большинстве роутеров можно автоматически прописать свой статический порт-маппинг (внутренний IP:port -> внешний номер порта), используя UPnP, чтобы гарантировать стабильность внешнего номера порта. Это вкратце, есть еще много нюансов. Всегда и везде p2p работать не будет, так что всегда нужно иметь запасной вариант с промежуточным сервером для таких "сложных" клиентов. |
| Автор: ter_nk_ 13.07.16, 08:49 |
| Pacific понял, спасибо, допустим можно просто использовать сервер для начала. Чтобы сервер понимал, что клиент онлайн, для минимизации расходов что лучше или тср соединение, там как бы понятно когда разрыв, или сделать посылку например udp пакетов по таймеру типа я есть? |
| Автор: Pacific 13.07.16, 11:39 |
| ter_nk_ Клиент может держать TCP-соединение с сервером, и общаться с другими клиентами напрямую. Через TCP клиенты и сервер будут обмениваться служебной информацией - всякие нотификации, кто вышел в онлайн/ушел в оффлайн и т.д. Трафик у сервера будет небольшой, но на каждого клиента будет свое соединение, так что один сервер потянет максимум миллион подключенных клиентов. С UDP соединения держать не надо, но для надежного обмена служебной информацией он не очень подойдет из-за потерь пакетов. |
| Автор: ter_nk_ 13.07.16, 11:46 |
| А если надо держать с сервером по ТСР каналу связь, может по нему же и передавать между клиентами информацию, если ее немного? Добавлено Клиент 2 - сервер, сервер - клиент1 |
| Автор: Pacific 13.07.16, 12:58 |
| Ну тогда это уже не p2p, а классическая модель сервер <-> клиенты. |
| Автор: ter_nk_ 13.07.16, 14:03 |
| Спасибо, сделаю из двух частей. |