Proxy сервер на 1000+ соединений на Delphi с исходным кодом

← →
Nucer (2010-01-26 17:55) [0]

Появилась задача написать быстрый proxy сервер, обслуживающий одновременно более 1000 соединений (грубо говоря, не такой, который обслуживает все соединения в одном потоке через select =)

Прокси должен просто "перенаправлять" соединения на другой порт без реализации какого-либо протокола типа socks5. Т. е. на машине работает основной сервер, держащий пару тысяч соединений на порту X. Клиенты соединяются с прокси по порту Y, который в свою очередь соединяется с сервером по X. Для сервера все остается без изменений кроме того, что входящий IP для всех соединений будет IP прокси.

Нужно для того, чтобы в случае необходимости была возможность анализировать и редактировать пересылаемые данные (исходных кодов оригинального сервера нет). Использовать локально LSP или внедрять DLL в процесс сервера не вариант, т. к. подразумевается запуск прокси на другой машине (или даже нескольких прокси на разных машинах).
Но все это потом. В первую очередь необходимо просто написать быстрый сервер, выполняющий роль буфера. Наверняка, такие уже написаны ни один раз, не хотелось бы заниматься велосипедостроением.

Если готовых болванок нет, то буду рад услышать советы по реализации. ТТХ: 1000-5000 соединений, время жизни соединения от нескольких минут до нескольких часов, 10+ Mb трафика в час в обоих направлениях для каждого соединения.

← →
Rouse_ © (2010-01-26 18:01) [1]

На сорсфорже посмотри, там этих проксей...

← →
turbouser © (2010-01-26 18:04) [2]

не совсем прокси, но думаю что подойдет
http://www.winton.org.uk/zebedee/

← →
Anatoly Podgoretsky © (2010-01-26 19:01) [3]

> Nucer (26.01.2010 17:55:00) [0]

10 mb это нагрузка для старинного модема, и смешная нагрузка при 5000 соединений, они что у тебя со скоростью 600 кб работают что ли. Потом ты ведешь речь про потока, а сумеешь такое количество потоков запустить, попробуй в цикле это сделать и потом сообщи результат.
Большинство прокси или ведут лог, или пишут в базу, для такого количества соединений только БД подходит. И нет нужды писать свой.

← →
Дмитрий С © (2010-01-26 20:10) [4]

Я на php такой напишу за час :) На дельфи часа за три, в чем проблема то?

← →
Rouse_ © (2010-01-26 20:52) [5]

Действительно - слово не воробей :)
Бери на слабо - вот тебе и аффтар нарисовался. Давай заказ Диме, если за три часа на дельфи не напишет и тебе код не покажет (а иначе как подтвердить то?), значит увы тебе и залет Диме - придется самому корячиться :)

← →
Nucer (2010-01-26 22:40) [6]

> 10 mb это нагрузка для старинного модема, и смешная нагрузка
> при 5000 соединений, они что у тебя со скоростью 600 кб
> работают что ли.

Я и не говорил, что видеопоток передается. 10 mb в час на соединение это 50 гигабайт в час для 5000 клиентов. Не так мало.

> Потом ты ведешь речь про потока, а сумеешь такое количество
> потоков запустить, попробуй в цикле это сделать и потом
> сообщи результат.

procedure TMyThread.Execute; var Start: Cardinal; begin Start := GetTickCount; while (GetTickCount - Start < 60000) and (not Terminated) do Sleep(100); end; procedure TForm1.btnActionClick(Sender: TObject); var I: Integer; T: TMyThread; Start: Cardinal; begin Start := GetTickCount; for I := 1 to 5000 do begin T := TMyThread.Create; T.Resume; btnAction.Caption := IntToStr(I); Application.ProcessMessages; end; btnAction.Caption := IntToStr(GetTickCount - Start) + " ms"; end;

На 2000 с копейками получил "Thread creation error: Недостаточно памяти для обработки команды". Есть какое-то ограничение или зависит от объема оперативной памяти?
Если не отдельный поток на каждое соединение, то как быть? Один поток на несколько?

← →
Rouse_ © (2010-01-26 22:47) [7]

В данном случае использование нитей есть ненужное и расточительное использование ресурсов. Смотри асинхронные варианты...

← →
Nucer (2010-01-26 23:05) [8]

> В данном случае использование нитей есть ненужное и расточительное
> использование ресурсов. Смотри асинхронные варианты...

А если на каждые 64 соединения использовать по потоку, работающему через select? Это будет лучше использования асинхронного режима, основанного на сообщениях? Все-таки обработка некоторых пакетов будет занимать определенное время (к примеру, иногда необходимо будет обращаться к БД и ждать ответа), поэтому одного потока явно не хватит.

← →
Rouse_ © (2010-01-26 23:19) [9]

> А если на каждые 64 соединения использовать по потоку, работающему
> через select?

Зачем? Тебе одного главноего потока даже работающего синхронно в режиме тупо перенаправления будет за глаза...

← →
Игорь Шевченко © (2010-01-27 00:06) [10]

> Есть какое-то ограничение или зависит от объема оперативной
> памяти?

http://blogs.technet.com/mark_russinovich/archive/2009/11/02/3290815.aspx

← →
Anatoly Podgoretsky © (2010-01-27 00:28) [11]

> Nucer (26.01.2010 22:40:06) [6]

Да и где ты 400 гбит найдешь, у нас даже локалки пока до 1 гб

← →
Дмитрий С © (2010-01-27 07:10) [12]

> Rouse_ © (26.01.10 20:52) [5]
>
> Действительно - слово не воробей :)

А не выйдет объективно, я это уже делал и там и там, конечно не за час и три:)

Автор говорит про select, значит представление о сокетах имеет, а логически задача простая.

> Да и где ты 400 гбит найдешь, у нас даже локалки пока до
> 1 гб

Так у него 400 гбит в час, это чуть больше 100 мбит/c

← →
Nucer (2010-01-27 11:24) [14]

> Игорь Шевченко © (27.01.10 00:06) [10]

Спасибо за ссылку. Вчера уже почитал на эту тему, но тут гораздо подробнее.

> Так у него 400 гбит в час, это чуть больше 100 мбит/c

Да, где-то так. Но реально загрузка 100 мегабитного канала в пиковое время около 70%.

> Автор говорит про select, значит представление о сокетах
> имеет, а логически задача простая.

Она простая, когда речь идет о десятках соединений, но когда стоит задача обслуживать одновременно несколько тысяч соединений (при чем число фактически удваивается, т. к. это прокси), то она (задача) на порядок усложняется (более того, при обработке некоторых пакетов придется делать запросы в БД и ждать ответа). Поэтому без продуманной архитектуры тут не обойтись (функции select в один поток явно не хватит). Для того и создал тему, чтобы спросить совета.

> Nucer (27.01.10 11:24) [14]

Для твоей задачи см. I/O Completion Port - вполне подойдёт.

> (более того, при обработке некоторых пакетов придется делать
> запросы в БД и ждать ответа)

А это для чего?

> Поэтому без продуманной архитектуры тут не обойтись (функции
> select в один поток явно не хватит).

Надо экспериментировать.

> Рамиль (27.01.2010 09:05:13) [13]

А в час, тогда другое дело, ну тогда нужен 1 гб канал, что кое где уже реально.

http://yandex.ru/yandsearch?text=IOCP+proxy&lr=237

Proxy сервер на 1000+ соединений на Delphi с исходным кодом Найти похожие ветки