Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Сокеты Windows и прокси сервер

Страницы: 1 2 >
DmitryA © (2009-11-04 18:45:00)
Как можно использовать стандартные функции работы с сокетами в Windows для прокси? В общем есть программы клиента и сервера, написанные на сокетах. Но между ними поставили проху. Как через него достучаться?

Андрей Смирнов (2009-12-01 08:19:00) [1]
Uses: WinInet;

// При помощи данной процедуры, можно установить Proxy, // через которую будет осуществляться работа в Internet, Proxy адрес указывается в // формате адрес : порт, например 195.43.67.33:8080. procedure ChangeProxy(aProxy: string); var PIInfo: PInternetProxyInfo; begin New(PIInfo); PIInfo^.dwAccessType := INTERNET_OPEN_TYPE_PROXY; PIInfo^.lpszProxy := PChar(aProxy); // Список адресов, доступ к которым осуществляется не через прокси PIInfo^.lpszProxyBypass := PChar(''); UrlMkSetSessionOption(INTERNET_OPTION_PROXY, piinfo, SizeOf(Internet_Proxy_Info), 0); Dispose(PIInfo); end; // Соединяемся с ЮРЛом с поддержкой прокси function GetUrl(const Url: string): string; var NetHandle: HINTERNET; UrlHandle: HINTERNET; Buffer: array[0..1024] of char; BytesRead: cardinal; begin Result := ''; NetHandle := InternetOpen(sfk_n, INTERNET_OPEN_TYPE_PRECONFIG, nil, nil, 0); if Assigned(NetHandle) then begin UrlHandle := InternetOpenUrl(NetHandle, PChar(Url), nil, 0, INTERNET_FLAG_RELOAD, 0); if Assigned(UrlHandle) then { UrlHandle правильный? Начинаем загрузку } begin FillChar(Buffer, SizeOf(Buffer), 0); repeat Result := Result + Buffer; FillChar(Buffer, SizeOf(Buffer), 0); InternetReadFile(UrlHandle, @Buffer, SizeOf(Buffer), BytesRead); until BytesRead = 0; InternetCloseHandle(UrlHandle); end else begin { UrlHandle неправильный. Генерируем исключительную ситуацию. } raise Exception.CreateFmt('Cannot open URL %s', [Url]); end; InternetCloseHandle(NetHandle); end else { NetHandle недопустимый. Генерируем исключительную ситуацию } raise Exception.Create('Unable to initialize Wininet'); end;

(Без авторизации!)

Медвежонок Пятачок (2009-11-09 15:41:00) [2]
это если он есть на прокси

FireMan_Alexey (2009-11-09 02:31:00) [3]
Проще использовать туннель предназначенный в протоколе НТТР.

Типа

CONNECT <имясервера>:<номер порта> HTTP/1.1
Host: <имясервера>:<номер порта>

Ждем

HTTP/1.1 200 OK

И можем слать что угодно... :)

Медвежонок Пятачок (2009-11-06 12:44:00) [4]
проще всего использовать между клиентом и сервером http протокол, а транспорт сделать на xmlhttprequest.
если браузер у юзера настроен, то все случится само собой

Anatoly Podgoretsky (2009-11-06 09:55:00) [5]

> Например, порт 4128, а протокол HTTP?

Это уже прозрачный прокси, ему ничего не надо знать, точнее клиенту ничего не надо знать.

Сергей М. (2009-11-06 08:19:00) [6]

> Как прокси знает, что на этом порте с ним будут общаться
> по известному протоколу?

Никак.
Прокси не будет обслуживать клиентов, разговаривающих с ним на неизвестном ему языке.

> порт 4128, а протокол HTTP

А вот на это существуют прокси, поддерживающие прозрачное проксирование, и маскарадные NAPT.

> нельзя привязываться жестко к какому-то прокси, т.к. их
> может быть несколько и разных

Без переделки/доработки клиента либо создания доп.софта, работающего в паре с клиентом прозрачно для него, задача не решаема

Демо (2009-11-05 20:11:00) [7]

> DmitryA (05.11.09 15:49) [10]
> Т.е. получается, без вариантов? Это как-то грустно ;(...
> Но работают же как-то другие системы или у нас в мире настолько
> все стало единообразно, что только стандартные системы рабоают?
>

Ну как же без вариантов?
Пишешь собственный прокси, в котором уже работаешь с чужим прокси.

DmitryA (2009-11-05 17:12:00) [8]
Так как его реализовать, если соединение по нестандартному (относительно существующих протоколов) порту? Как прокси знает, что на этом порте с ним будут общаться по известному протоколу? Например, порт 4128, а протокол HTTP? И нельзя привязываться жестко к какому-то прокси, т.к. их может быть несколько и разных.

Anatoly Podgoretsky (2009-11-05 17:06:00) [9]
> DmitryA (05.11.2009 16:50:14) [14]

Это так и согласно вопросу, придется реализовывать и 7 уровень, тоже

DmitryA (2009-11-05 16:50:00) [10]
Все дело в том, что работа через сокеты это на уровень ниже всяких протоколов. Это означает также и полное отсутсвие авторизации в том числе. Т.е. соединение между клиентом и сервером либо физически установлено, либо нет. И сдесь нет понятия кого-то еще (прокси), который требует авторизации по какому-то формату в зависимости от типа протокола. Я могу ошибаться, прокси работает на 7 уровне (прикладной), а сокеты на 4 (транспортный). Поэтому мне непонятно как процесс на уровне 4 может общаться с процессом на уровне 7?

Anatoly Podgoretsky (2009-11-05 16:20:00) [11]
> DmitryA (05.11.2009 16:15:12) [12]

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

DmitryA (2009-11-05 16:15:00) [12]
Вот это-то и понятно. Но как это сделать имея только класс типа TCustomIpClient?

Anatoly Podgoretsky (2009-11-05 16:01:00) [13]
> DmitryA (05.11.2009 15:42:09) [9]

Самописный протокол требует и самописного подключения к прокси.

DmitryA (2009-11-05 15:49:00) [14]
Т.е. получается, без вариантов? Это как-то грустно ;(... Но работают же как-то другие системы или у нас в мире настолько все стало единообразно, что только стандартные системы рабоают?

DmitryA (2009-11-05 15:42:00) [15]
Используется самописный протокол.

Anatoly Podgoretsky (2009-11-05 14:48:00) [16]
Иногда прокси называют сессионную систему авторизации. Когда выпуск во вне производится по паролю на сессию. Это просто выключатель, если включено, то пакеты идут дальше, если нет, то умирают.

Anatoly Podgoretsky (2009-11-05 14:46:00) [17]

> DmitryA (05.11.09 12:49) [2]

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

Сергей М. (2009-11-05 14:16:00) [18]

> Есть уже написанный сервер

И пусть он себе есть - его этот вопрос совершенно не касается.

> На это уровне нет понятия протокола (HTTP, и HTTPS, и SOCKS4/4a/5)

Совершенно верно.

> и разные клиенты

Они на каком языке с сервером разговаривают ?
Какой-то стандартный прикладной протокол используется или самописный ?

DmitryA (2009-11-05 13:51:00) [19]
Это мне понятно, но задача в другом. Есть уже написанный сервер и разные клиенты, которые работают используя WinSock, типа TCustomIpClient. И у них только свойство LocalHost (Specifies the name of the local system) и RemoteHost (Specifies the name of the remote system). Так говорит хелп. На это уровне нет понятия протокола (HTTP, и HTTPS, и SOCKS4/4a/5). Т.е. если у прокси стоит не прорачное проксирование , то клиент вообще не может никуда выйти, прокси его не пускает. Тем более мне непонятно как быть в случае авторизации на прокси, т.к. на это уровне нет понятия авторизации. Или я вообще ничего не понимаю?!

Сергей М. (2009-11-05 13:08:00) [20]

> У сокета только одно соединение на один хост, а тут получается
> 2, одно на прокси, второе - целевое (конечное).

И тут тоже получается одно - к прокси-серверу.
А тот уже, по просьбе клиента на языке соответствующего прокси-протокола, соединяется с целевым сервером.
На то он и прокси (от англ. proxy - посредник), чтобы быть посредником в коммуникациях между клиентами и серверами.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »