интересует вопрос как реализовать прямой коннект между двумя машинами через глобальную сеть интернет.
На сколько я понимаю, обычные сокеты не подойдут , ибо машин может например находится за проксёй или НАТом.

Принцип установки соедения как в p2p серверах : сходил на сервер , получил там ИП напарника, и дальше уже работаеь с напарником (без сервера!).

Сокет это механизм, к firewall или NAT отношения не имеет. По идее клиент, сидящий за NAT'ом может попросить раутер пропускать коннекты, курить это. Гугл выдал это.
Это головная боль клиента (человека) заставить раутер пропускать коннекты, если железо старое, то настройкой в ручную 
А дальше как обычно, узнаём IP:port либо с сервера, либо от других клиентов, подключаемся сокетами.

Таким образом клиенты только находят друг друга, а вот установка связи это совсем другое. Если оба клиента сидят за NAT, firewall, proxy (и порт форвардинг настроить нельзя), то соединяться они могут только через сервер.

LSD, а как же торренты, уверен большинство их использующих - это люди за натом.
ладно попробую разобратся в исходниках какого опен сорс торрента ...

А ты почитай FAQ-ки по торрентам, там есть куча вопросов как реализовать проброску портов на роутере. В любом торрент клиенте есть индикатор показывающий виден ли он "снаружи".

К примеру Azureus, самый частый вопрос NAT problem.

Выходит в качестве механизма я могу использовать сокеты и мне надо что бы один из компьютеров имел в интернете свой ИП (он будет сервером) а другой будет к нему конектится.

Добавлено через 11 секунд
это не есть ахти хорошо (.

Нет. Сидящий за NAT'ом человек видим как (IP:port), IP обычно (один из) IP раутера организующего NAT. При этом ты с другого конца даже не подозреваешь, что человек за NAT'ом. Эта связка публикуется на треккере, либо распространяется через других клиентов, т.е. "статический IP" не нужен. Оба клиента оповещают раутер (UPnP, либо ручной port forwarding), что хотят принимать пакеты, открывают серверный сокет, ждут.

если проект для широкой аудитории - т.е. пользователи могут не иметь достаточной квалификации или не иметь возможности настроить локальную сеть (в офисах), то единственный способ соединения - по http через сервер посредник. 

рассматривается ситуация когда нет доступа до роутера для проброски портов.


это будет не очень быстро + будет грузить сервер лишним траффиком...

Так работают все системы, или через центральный сервер или один из клиентов должен иметь внешний IP. В принципе, можно этого самого клиента использовать как сервер для других клиентов не имеющих внешнего IP. Но тут надо не переборщить, чтобы не забить его канал на 100%.

Повторяю:

• все машины в сети имеют внешний IP, иначе адресация не возможна (говорим о самых концах сетки, где реально идут пакеты IP)
• NAT это способ расшарить один или несколько внешних IP между локальной сеткой машин
• на работу сети это никак не влияет, коннекты по прежнему сокетом (IP:port) <- -> (IP:port)

Поняв эти три истины задумываемся, а как же раутер организующий NAT может знать куда у себя в локалке пакет пересылать?
Ответ: существуют два типа соединений:

• исходящие из локалки - раутер выделяет временно внешний (IP:port), port произвольный и регистрирует связь этого внешнего IP адреса с локальным. Исходящие пакеты уходят "от имени" этого внешнего IP. Для входящих пакетов раоутер смотрит на какой порт пришёл пакет и ищет связь на локальный адрес, если нашёл - пакет уходит к локальной машине, иначе выбрасывается. После закрытия коннекта связь локального и внешнего (IP:port) удаляется.
• постоянные входящие - тут сложней, т.к. без заявки на (IP:port) раутер просто отбросит пакет, не зная куда его переслать дальше. Два варианта, либо пользователь настраивает port forwarding, т.е. запрашивает себе постоянный внешний (IP:port) <-> (локальный IP:тот же порт). К примеру у меня в домашней сетке сети 80 идёт на 192.158.1.105 - мой локальный IP. Конечно нужно DHCP настроть, что бы выдавал тебе тот же локальный адрес - ясно что это не удобно.
  UPnP создаёт port forwarding на лету, т.е. не нужно просить DHCP выдавать один и тот же адрес либо пользоваться статичными локальными адресами и не нужно самому править таблицы портов раутера. Прога обращается к раутеру и запрашивает внешний (IP:port), регистрируется семи-постоянная связь на локалку. Дальше идеентично исходящим коннектам, но связь внешнего (IP:port) с локальным адресом после закрытия коннекта не удаляется.

Я думаю не должно остаться вопросов? Максимум что ты можешь сделать из своей проги - это настроить раутер пользуя UPnP, штука простая, жаль не безопасная, потому не везде есть. Никому из клиентов не нужно иметь постоянный внешний IP, мало того никто из них не будет знать, что кто-то под NAT'ом (кроме себя естественно). На работу сети никак не влияет, у всех есть (не постоянный) внешний (IP:порт)  (порт обязателен, именно по нему различаются несколько машин на одном IP, отсюда понятно почему произвольные IP пакеты не возможны, за NAT'ом только TCP/UDP).

Добавлено через 6 минут и 51 секунду
Млин, кажись не понял сути поста LSD, извиняюсь 
Да, треккер должен иметь постоянный IP, иначе клиентам не известно куда обращаться. Но это только seed, затем клиенты расшаривают свои списки других знакомых адресов, "облака" сеток склеиваются. Так Gnutella работает, довольно медленно...

Всегда найдутся клиенты, для которых по разным причинам возможно соединение только по http на 80 порт. Поэтому клиентское приложение должно иметь возможность соединения по нескольким протоколам. Сначала делается попытка соединиться по "быстрым" протоколам. В случае неудачи осуществляется переход на "медленный" http. Такой принцип используется в RMI и упомянутых файлообменных системах.     

уу ... как круто ... хотья это наверное найболее оптимальный выход!