Здравствуйте, Michael Chelnokov, Вы писали:

MC>О какой производительности (точнее, издержках TCP) идет речь при таких больших обьектах?
MC>Ну а аргумент про NAT'ы совсем непонятен. В случае TCP наружу должен торчать только сервер, в случае UDP — оба конца. Где в случае UDP отсутствие проблемы с NAT'ами?

Система одноранговая (P2P) и в случае большого количества "соседей", а так же в силу их динамизма, создавать TCP подключения выходит накладнее чем использование UDP транспорта.

Проблема с TCP и NAT следующая: Я предполагаю открывать "окно" между 2мя узлами, находящимися за NAT'ом следующим образом. Допустим, текущий p2p оверлей состоит из 1го узла с паблик IP (A) и одного узла за NAT (B). К оверлею подключается новый узел (C), и ему необходимо соединиться с узлом (B). Используется помощь узла (А) — через него (B) и (С) обмениваются своими внешними адресами. Далее они начинают синхронно обмениваться пакетами по протоколу TCP. После того, как узел (В) пошлет пакет узлу (C), NAT узла (B) определенное время будет пропускать пакеты от узла (C) по этому адресу и можно будет установить соединение. Проблема с TCP в том, что как привязать 2 сокета на один адрес (слушающий сокет и сокет отправляющий сообщения для открытия "окна" узлу (C) ).