Если я все правильно понял, то работает это так: A и B хотят общаться p2p. A отправляет пакет на сервер S, B отправляет пакет на S. Remote endpoint (ip:port), который сервер увидит в пакете от A (то есть ip:port NAT-овского сервера A, с которого ушел пакет) сервер подсовывает в качестве отправителя, когда отвечает компьютеру B. Тоже самое делается для ответа компьютеру A. Далее A и B общаются напрямую. Все так, или я что-то упустил? У меня есть два вывода (поправьте, если я ошибаюсь): 1. Средствами UDP дырку не просверлить, т.к. нужно хачить пакеты. Получается, на сервере нужно юзать raw sockets? 2. Клиенты ничего не знают про сверление дырок, знают только что сначала надо отправить запрос и ждать ответа. Сделовательно они могут юзать любые сетевые библиотеки.
Нет, так не выйдет. Cервер передаёт клиентам информацию и далее они работают напрямую. Возможно это далеко не всегда, а именно когда Cone NAT или Address-Restricted cone NAT. http://aoz.com.ua/2009/01/26/nat-types/
По пункту 1, я понял что подразумевается подмена адреса и порта. Такого нет, как и не нужны сырые сокеты, по-этому по-моему другое.
Booster Если не делать подмену адреса и порта, то каким образом будет идти p2p? NAT ведь не пустит пакеты, пришедшие от левого отправителя?
Они просто каким-либо образом передаются клиентам в юзер протоколе, а те уже коннектятся друг к другу. Подмена в пакете ничего не даёт и это ахтунг.
>Дык не могут они коннектиться друг к другу без хаков - NAT же такие прямые соединения не пустит. Как это не могут? На сервер уже пришли внешние адреса клиентов, по ним клиенты и коннектятся друг к другу. Но опять таки, это далеко не всегда возможно, зависит от типа ната. Если нат под каждое соединение заводит отдельный адрес, то обломс. Почитай про типы натов, по ссылке которую я дал, должно проянить.