Стоит вопрос обмена файлами между приложениями у пользователя.
Понятно, что пользователи могут сидеть в сети через NAT. вернее даже не "могут", а большая часть за НАТом.
В связи с чем приложения должны работать через STUN. Писать свою реализацию очень не хочется. В связи с чем ищется готовый код реализующий данный функционал.

> Писать свою реализацию очень не хочется.

Она очень простая, протокол простой. Вот здесь есть модуль STUN.pas, код так себе на мой взгляд, но в качестве основы пойдет

http://tothpaul.free.fr/zip/SIPInside-0.4.9-src.zip

Этот код я видел. Но он же только позволяет получить инфу о NAT.
Я видимо не верную терминологию использовал.
Мне нужно соединить два компа за NAT посредством внешнего сервера.

Если они оба находятся за Full Cone NAT, то нет проблем - кинули друг другу UDP сообщения на указанный порт и работают.
Но там же несколько вариантов, вот и надо их реализовывать. Вроде бы ничего сложного, но писать все это очень не хочется...

port restricted NAT еще есть шанс пробить, а вот address rectricted вряд ли.

Поступило предложение просто настраивать на компах teredo и работать по IPv6

> @!!ex ©   (30.04.13 15:20) 

все эти STUNы и т.п. хаки - редкая экзотика, времени отнимет уйму, а работать будет в 0.5% случаев, а то и реже. в общем, и самом распространенном, случае, NAT не пробивается, нужно исходить из этого.

> @!!ex ©   (01.05.13 00:32) [4]


imho бессмысленная затея.
Если НАТ приемника "пробиваемый", то никакой тередо нафих не нужен.
А если непробиваемый, то никаким p2p при teredo даже не пахнет - данные так или иначе идут через публичные или частные teredo-серверы/релеи, со всем вытекающими последствиями.

> в общем, и самом распространенном, случае, NAT не пробивается, нужно исходить из этого.
В самом распространенном случае как раз пробивается. У всех самых распространенных провайдеров России Full Cone, который хорошо пробивается. Symetric в основном только у мобильных операторов, но их клиенты с моими не пересекаются. Так что я с тобой не согласен.

>Если НАТ приемника "пробиваемый", то никакой тередо нафих не нужен.
А тут все просто. Я делаю на базе IPv6, и просто даю инструкцию как сделать чтобы это работало. Те, у кого честный IPv6 вообще заморачиваться не будут, те у кого IPv6 нет, просто настроят teredo и опять же все будет работать.
Писать свой туннель вместо встроенного тередо мне видится странным.

>данные так или иначе идут через публичные или частные teredo-серверы/релеи, со всем вытекающими последствиями.
Даже если и так, главное, что это не через мои сервера будет идти.

> главное, что это не через мои сервера будет идти


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

Да, но в случае с teredo мне не надо просить пользователя что-то дополнительно ставить, все уже есть в системе. А если у него еще и IPv6 нативный, то ему вообще никаких телодвижений делать не придется. И в случае обмена в одной подсети - все гарантированно будет идти напрямую.
А к IPv6 мы рано или поздно все равно придем.

> @!!ex ©   (01.05.13 16:33) [7]


> У всех самых распространенных провайдеров России Full Cone

тут два соображения:
1. попробуй протестировать эту самую пробиваемость на практике, сторонним софтом, к примеру. подозреваю, что в большинстве случаев никто никуда не пробъется.
2. огромное количество людей сидит через ADSL модемы, их надо специально конфигурировать, иначе затык будет именно на модеме.

это я не теоретизирую, несколько лет назад стояла задача рассмотреть все возможные варианты пробивания NAT, на практике все эти пробивания - пустая трата времени, нужно разворачивать свои сервера, только это даст 99% гарантию работы.

> У всех самых распространенных провайдеров России Full Cone


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

Кстати, вот под рукой оказалась утилитка на эту тему
http://zalil.ru/34479193

Верить или не верить выдаваемым ею результатам - каждый решает сам)

Моя цель не домашние юзеры. Поэтому такой проблемы не стоит.
Главное чтобы у провайдера было нормальное железо. А уж пользователь пусть со своим железом сам разбирается.
Конечно, в идеале, чтобы у всех все работало само и из коробки. Но делать это нет ни ресурсов, ни желания.

Сейчас другой вопрос. у меня Indy отказывается работать с IPv6.