Есть некий проект, представляющий собой клиент-серверное приложение (клиенты через Интернет работают с сервером). Проект пока в стадии разработки, однако, основное уже сделано.

Сервер представляет собой консольную программу на вижуал сипп. Сидим на порту и принимаем юдп пакеты. Надо сказать, что сетевой движок у программы достаточно мощный. На прикладном уровне над юдп реализована вся функциональность tcp. Ну, так захотелось, но не в этом суть.

Клиент есть ВБ6 программа, которая по ЮДП, как вы уже поняли, вяжется с сервером.

Короче, это стратегическая пошаговая игра. Трафик мизерный, число пакетов за час – ничтожное. ЮДП полностью устраивает, так как важно чтобы сообщение просто слалось (а на юдп это просто), а уж его доставку, перепосылку и т.д. – это уже я сам разберусь.

И всё замечательно работает. Казалось бы, горя не знай. Но случилась беда.

Оказалось, что всё работает, когда у клиента нормальный интер. А если клиент находится на машине в корпоративной сети, защищённой фаерами и прочим отстоем, то, ессно, попасть на сервер он не может. Подбривка юдп трафика – это, как выясняется, практически святое дело в любой конторе.

ЧТО ДЕЛАТЬ-ТО? Нужно универсальное решение, как для средстатистического случая замимикрировать трафик. Чтобы пролезало везде.

Подо что и как маскироваться? Чтобы было дёшево в реализации (я не супер сетевой гуру-программист). Желательно, чтобы не пришлось корёжить уже существующий алгоритм сетевого движка. То есть, в идеале, нужно спрограммировать что-то, что инкапсулировало бы (или тунеллировало бы) мой юдп трафик в себя, а на стороне сервера _это_ выпускало бы его опять наружу, то есть на вход серверу.

Ещё есть проблема. Сервер должен знать адрес и порт с которого с ним общается клиент. Хотя при обертке трафика это можно было бы решить и на прикладном уровне, просто кладя эту инфу в само сообщение.

Либо, как вариант, внешняя бесплатная программа, которая перенаправляла бы траф нужным образом.

Ну и опять, подо что маскироваться, чтобы гарантированно просачиваться в большинстве случаев? Под хттп, создавая тэсипи соединение? Или какие-нить почтовые проколы? К сожалению, мало чего знаю про это. Посоветуйте, пожалста, чего-нить… 

Ну, только http (tcp, port 80) и остается (остальное уже не гарантируется). Делай надстройку. 

1. Клиент у тебя может сидеть:
a)  на нормальном IP адресе (только в этом случае полностью можешь гарантировать UDP
b) на интранет через NAT
c) на интранет через proxy

С учетом пп. bc) от UDP лучше отказатся (либо сопровождать параллеьно и UDP и TCP варианты.

В настройках клиента - указываешь тип подключения и его параметры, включая протокол (например 80-83 и 8080 как правило разрешены) и адрес сервера

На сервере открытые порты тоже лучше указывать в конфиге.

Оптимальный вариант - создаешь абстрактный класс (интерфейс) инкапсулирующий функции send()/recive()/sessionID() и интерфейс демиурга с функциями HandShake()/CreateSession()/RestoreSession()/DropSession().

Фабрика класса создателей сессий - в зависимости от настроек etc - создает/выбирает демиурга, который и генерит реальные сессии.

Соответственно на стороне клиента - в зависимости от настроек, на стороне сервера - можешь либо запускать 2 демона (1 из них proxy), либо одного принимающего все, что шевелится



 

Slava72! Большое спасибо за отзыв, пока никто на нескольких форумах, кроме тебя, ничего не смог мне сказать и помочь.
Не буду хвастаться, что многое (слишком круто ты всё объяснил!) понял из того, что ты сказал, но постараюсь на словах объяснить, как я себе это представляю, так сказать алгоритм. Ты поправь меня плз, если я где косячу.

1) В клиенте выставляем галочку «работа из-под локалки». Это означает, что теперь выходная очередь ЮДП сообщений шлётся не на правильный адрес сервака в интере, а на 127.0.0.1:P2, где P2 специальный фиксированный порт, на котором на клиенте же сидит наш процесс или поток «Пересыльщик1», который и «проникает сквозь врага». Таким образом, весь сетевой движок клиента не меняется, и, по сути, движку пофиг, его задача по-прежнему выплюнуть ЮДП пакет. (Уточнение: адрес клиента в локалке обозначим как IP. Оригинальный порт клиента, который ему дала система пусть будет P1. Разумеется, жёстко не биндимся, ведь на одном адресе IP может крутится несколько клиентов.)
2) Пересыльщик1, получив ЮДП пакет, распаковывает его, добавляет в тело оригинальный адрес:порт отправитель (IP:P1) и специальный флаг, что работаем из стана врага. Далее опять запаковываем пакет.
2.2) Наше бинарное, по сути, сообщение маскируем в тупой хтмл-запрос. Надо ли это? И КАК?!
2.5) Возможно что-то пропущено по настройке Пересыльщика1. То есть надо, может быть, что-то предусмотреть по настройке в зависимости от «местного» сетевого полиси и условий, но ЧТО?!
3) Пересыльщик1 создаёт TCP соединение с серваком - соединение с его реальным интеровским адресом (постоянным, который обозначим как ip), а серваковский порт обозначим как p2, он специально предназначен для приёма соединений «локальщиков». Штатный ЮДП порт на сервере для клиентов с правильным интером обозначим как p1.
4) Пересыльщик1 отправляет на ip:p2 пакет.
4.5) Вопрос, а какая у нас далее стратегия? Устанавливаем соединение на постоянку? Или, например, будем коннектиться к серваку раз в пару секунд и скидывать или получать если есть чего, а потом рвать, и через пару секунд по-новой?
6) Поток на сервере, устанавливающий соединения и принимающий пакеты от «локальщиков», распаковывает пакет и уже на прикладном уровне СЕРВЕРА вставляет его во входную очередь сообщений (не операционки, а самой программы-сервера игры) в прикладном плане. Сервер должен знать онлайн-игроков «в лицо».
7) Прикладуха сервака обрабатывает сообщение как ни в чём не бывало, и ставит ответ на него в выходную очередь сетевого движка. Ессно, что когда поток сервера, отвечающий за рассылку сообщений сервера, доходит до такого сообщения, то он «понимает», что клиент у нас локальщик и слать надо не по ЮДП на IP:P1, а ждать пока приконнектится клиент опять и скинуть ему данные.
7.5) Маскироваться надо под html-запрос?
8) Пересыльщик1 получив пакет от сервака посылает его на IP:P1 по ЮДП.

Вуаля! Или я ничего не понял? Или можно проще и красивее? Заранее большое спасибо за участие.
 

Имхо 

ненадо,
а на кой заморачиватся с пересыльщиком? имхо проще создать просто 2 ветви посылки сообщения :
1. по юдп
2. по тсп, через прокси