Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[13.59.218.147] |
|
Сообщ.
#1
,
|
|
|
Чтобы организовать соединение между например мобильным устройством и компьютером должен быть сервер с IP, отправляем ему по UDP что я такой-то. В локалке он один, сервер видит его другим, другое устройство так же посылает пакет, сервер видит его уже другим. Сервер может одному устройству послать внешний айпишник и порт другого, но оба то одновременно в сети они не видны. Как то я тут немного запутался, просветите.
Есть еще так понимаю для этого STUN сервера. |
Сообщ.
#2
,
|
|
|
Стоит сформулировать вопрос. Мало что понятно из приведенного выше..
|
Сообщ.
#3
,
|
|
|
p2p как лучше реализовать, собственно пока теоретически.
|
Сообщ.
#4
,
|
|
|
А погуглить?
|
Сообщ.
#5
,
|
|
|
Цитата Oleg2004 @ А погуглить? Нагуглил snupserver, у меня вопрос теоретический пока, как лучше сделать, а не как вообще сделать, реализовать как-нибудь я могу. |
Сообщ.
#6
,
|
|
|
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 работать не будет, так что всегда нужно иметь запасной вариант с промежуточным сервером для таких "сложных" клиентов. |
Сообщ.
#7
,
|
|
|
Pacific понял, спасибо, допустим можно просто использовать сервер для начала. Чтобы сервер понимал, что клиент онлайн, для минимизации расходов что лучше или тср соединение, там как бы понятно когда разрыв, или сделать посылку например udp пакетов по таймеру типа я есть?
|
Сообщ.
#8
,
|
|
|
ter_nk_
Клиент может держать TCP-соединение с сервером, и общаться с другими клиентами напрямую. Через TCP клиенты и сервер будут обмениваться служебной информацией - всякие нотификации, кто вышел в онлайн/ушел в оффлайн и т.д. Трафик у сервера будет небольшой, но на каждого клиента будет свое соединение, так что один сервер потянет максимум миллион подключенных клиентов. С UDP соединения держать не надо, но для надежного обмена служебной информацией он не очень подойдет из-за потерь пакетов. |
Сообщ.
#9
,
|
|
|
А если надо держать с сервером по ТСР каналу связь, может по нему же и передавать между клиентами информацию, если ее немного?
Добавлено Клиент 2 - сервер, сервер - клиент1 |
Сообщ.
#10
,
|
|
|
Ну тогда это уже не p2p, а классическая модель сервер <-> клиенты.
|
Сообщ.
#11
,
|
|
|
Цитата Pacific @ Ну тогда это уже не p2p, а классическая модель сервер <-> клиенты. Спасибо, сделаю из двух частей. |