А что будет быстрее работать при написании приложения для сети?

← →
nester © (2004-04-09 16:08) [0]

Меня интересует намного ли будет тормознутее работать сетевая прога написаная на Делфи/Kylix под линух по сравнению с С.
Специфика проги - Держать много открытых коннекшенов TCP и обменивать данные между ними.
Коннекшенов будет ооооочень много, порядка милионов, ну железо тоже будет соответствующее.
Вод думаю на Делфи/Kylix под линух писать. Но прежде интересуюсь на сколько это медленнее будет работать, желательно ответ услышать типа примерно в х раз%)))
Заранее благадарю

← →
Reindeer Moss Eater © (2004-04-09 16:19) [1]

Данными по сети обмениваются не сами программы написанные на С или Delphi.
Реальную работу выполняют модули стека протоколов которые написаны на С.
Программы лишь вызывают функци этих библиотек. Так что все будет одинаково. Примерно одинаково.

← →
Digitman © (2004-04-09 16:21) [2]

> Коннекшенов будет ооооочень много, порядка милионов

никак новую "а-ля ICQ" сеть сотворяем ?)

← →
nester © (2004-04-09 16:26) [3]

Угадал%)))
За что деньги платять то и делаемс:)))
Тогда такой вопрос, а с памятью как дела обстоять будут?
Это же на каждый коннекшн будет выделяться память, вот интересно, она будет выделяться дефовскими мерками или сишными?
А то если на каждый коннешкшен кил эдак по 50 - то никакой оперативы не хватит.
И еще вопрос такой тогда - как лучше написать, все через сервер или лучше директ коннекшинами когда возможно?

← →
Reindeer Moss Eater © (2004-04-09 16:28) [4]

Это же на каждый коннекшн будет выделяться память, вот интересно, она будет выделяться дефовскими мерками или сишными?

Он так и не понял, что хоть на VB пиши, но сокеты и память под них будет выделяться стеком протоколов.

← →
nester © (2004-04-09 16:35) [5]

Теперь понял. :)))

← →
Digitman © (2004-04-09 16:37) [6]

> Это же на каждый коннекшн будет выделяться память

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

← →
Digitman © (2004-04-09 16:41) [7]

> nester © (09.04.04 16:35) [5]

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

← →
nester © (2004-04-09 16:46) [8]

:)))ето я понял.
В sysctl мнеяется етот параметр на большее число.
64-х битная версия SuSe Linux поддерживает более 65k коннекшенов. Сейчас на сервере, где я работаю стоит 100к коннекшенов. А ето редхат 9.
А вообще етот параметр можно менять при перекомпиляции ядра как мне кажется, как ядро вы компильнете - так оно и поплывет:)))

← →
Verg © (2004-04-09 16:58) [9]

> nester © (09.04.04 16:46) [8]

> 64-х битная версия SuSe Linux поддерживает более 65k коннекшенов.

В протоколе TCP порт задается 16-битовам числом.

Как же назаначаются в этой замечательной SuSe Linux эти значения ф-цией accept, когда диапазон в 65к, обусловленный протоколом, заканчивается?

← →
Digitman © (2004-04-09 17:02) [10]

> nester © (09.04.04 16:46) [8]

да компилять-то ядро ты волен как угодно)

но вот если вознамерился пользовать именно TCP, то компиляй не компиляй свое ядро, а выше дозволенного протоколом не прыгнешь - поля "порт отправителя" и "порт получателя" в заголовке дейтаграммы этого протокола 16-битные

← →
Verg © (2004-04-09 17:22) [11]

> Digitman © (09.04.04 17:02) [10]

Для сервера, впрочем, это не так важно.

← →
Digitman © (2004-04-09 17:26) [12]

> Verg © (09.04.04 17:22) [11]

поясни свою мысль ..

← →
Verg © (2004-04-09 17:28) [13]

> nester © (09.04.04 16:08)

Не, и все же мне не очень понятно: "Держать много открытых коннекшенов TCP... " - это поддерживать соединения или принимать входящие.

← →
nester © (2004-04-09 17:38) [14]

Похоже мы о раззных вещах говорим.
Я говорю о file-max. Я имел в виду максимально возможное число открытых дискрипторов. оно по умолчанию кажется у редхата 7 1024 стоит - вечно былы с этим проблеммы на больших серверах. И действительно максимум можно было поставить 65к, но сисадмин както ето решил. Я так понял перекомпилял ядро.

Теперь я понял о чем тут речь ведется. Мне кажется господа вы путаете понятия соединения и порт. Сервис будет на одном фиксированом порту висеть(может на нескольких).
Я не собираюсь на каждого юзверя выделять по порту%))) все в один%))) Как по вашему апач работает?
Число возможных соединений решается довольно просто - много айпишников у одного сервера(скажем n). Следовательно число возможных открытых одновременоо сокетов будет 65к*n - ну а остальное упреться в производительность сервера и максимальное число открытых дискрипторов(которое задается перекомпилированием ядра)

Единственное что мне никогда понятно не было - так это почему можно делать много соединений на одном порту??? сам писал много программ которые так делали, но как это работает на низком уровне - понятия не имею, как апач висит на одном порту а обрабатывает много соединений?

← →
Verg © (2004-04-09 17:39) [15]

> Digitman © (09.04.04 17:26) [12]

А.а! Вон что: я там перепутал - там там не accept, а connect конечно.
У сервера-то как раз все должно быть нормально.

← →
nester © (2004-04-09 17:42) [16]

2Verg [13]
> "Держать много открытых коннекшенов TCP... " - это поддерживать соединения или принимать входящие.

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

← →
Verg © (2004-04-09 17:47) [17]

> nester © (09.04.04 17:42) [16]

Да нет, я не про то спрашиваю. Я про, - это будет клиент, который устанавливает и поддерживает соединения, или это будет сервер, который долже справится с таким количеством входящих седенений?

← →
Digitman © (2004-04-09 17:50) [18]

> почему можно делать много соединений на одном порту

как раз нельзя

виртуальная петля соединения однозначно определяется на каждой из сторон комбинацией "адрес:порт"

← →
Verg © (2004-04-09 17:54) [19]

> Digitman © (09.04.04 17:50) [18]

Четверкой чисел адрес:порт(local)-адрес:порт(remote)

← →
Digitman © (2004-04-09 17:56) [20]

> Verg © (09.04.04 17:54) [19]

ну да ... уточнение правильно

← →
nester © (2004-04-09 17:58) [21]

Ето сервер будет:)) который должен с этим справиться:)
У клиента будет одно соединение - к серверу и все. С клиентом вопросов не возникает. Впрос с сервером, хочу прикинуть потянет ли все ето киликс или нет?
Или на С писать - но на С у нас программеров нет в конторе - придется нанимать когото:(
Вот я и хотел узнать, можно на киликсе такое потянуть или нет? Нужен программер С или киликсом обойтись можно.
В начале планируется поставить дуал Оптерон(ето AMD 64-битный) с двумя гигами оперативки под SuSe Linux, вот хочу узнать сколько такая тачка выдержит? То что все обрабатываться сишным кодом, который написан задолго до меня, и то что мне только нужно вызывать нужное - я уже понял, а что киликсу останется? или киликс будет переводиться в сишный код и компиляться как сишный код? Я сомневаюсь в этом.
И еще вопрос какую базу данных лучше использовать, MySQL мне кажется сдохнет, но не уверен.
Для базы требования простые - быстрая выборка селектов.
Всякие утяжеления типа транзакции и хранимые процедуры не нужны.
Интербэйз(точнее его бесплатная версия файрберд кажется зовется) кажется тяжеловат, или его можно скомпилять без поддержки хранимых процедур и транзакций?

← →
nester © (2004-04-09 18:02) [22]

2Digitman [18]
А как апач весит на одном порту?
Или каждому соединению порт переопределяется?
Или как?
В любом случае решается все просто - добавлением айпишников для одного сервера

← →
Digitman © (2004-04-09 18:07) [23]

> nester © (09.04.04 18:02) [22]

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

← →
Verg © (2004-04-09 18:07) [24]

> Впрос с сервером, хочу прикинуть потянет ли все ето киликс
> или нет?

Так не Киликс же "тянуть"-то будет, а программа на нем написанная и откомпилированная. Все зависит от того, как будет написана программа.
Ты в чем сомневаешься - в оптимизаторе Киликса или в чем?

Это как справшивать - на каком Асм-е программа будет работать быстрее - на At&T-шном или на MASM-е.

← →
Digitman © (2004-04-09 18:11) [25]

> В любом случае решается все просто - добавлением айпишников
> для одного сервера

вот чтобы получить около миллиона одновременных коннектов, тебе и придется не менее 16 "айпишников" добавлять

а ты о клиенте подумал ? он как, по твоему, будет искать сервер, ежели заранее не знает, какой из "айпишников" в дан.момент имеет возможность акцептировать его запрос ?

нет, это несколько по-другому реализуется ...

← →
nester © (2004-04-09 18:16) [26]

Я сомниваюсь в оптимизаторе:))), я думал это и так понятно.
Насколько будет оптимально
Я сомниваюсь в оптимальности скомпелированого кода:)))
Точно так же как разница между программами написаными на делфи и си под винду(ну или масме :))). При этом я понимаю разницу в трудозатратах.

2Digitman[23] - спасибо, я примерно так и представлял себе, теперь убедился.
Т.е. вопрос на число открытых соединений решается добавлением айпишников:)))

← →
Verg © (2004-04-09 18:17) [27]

> Digitman © (09.04.04 18:07) [23]

Погоди, погоди....
При accept-е образуется "присоединенный" сокет, localport, которого равен порту слушающего сокета от которого он с-accept-ился.

← →
nester © (2004-04-09 18:23) [28]

2Digitman [25] А ето мне кажется просто очень будет. На одно доменное имя привязать 16 айпишников, ДНС сервера будут выдавать их примерно случайно и нагрузка как показывает опыт распределяется болееменее равномерно с разницей примерно 15-20%(не очень большой разброс)
Тогда возникает вопрос а какой ето ДНС сервер сразу будет успевать раздавать так быстро айпишники%)))?
Ну а для етого у каждого провайдера каждого уровня есть свой кэширующий ДНС сервер, он по каждому запросу не будет лезть на основной, а будет выдавать айпишник из кэша.
Проверяли уже:)))

← →
nester © (2004-04-09 18:26) [29]

В конечном счете можно будет заложить в протокол выбор айпишника при запросе с сервера. Типа основной айпишник, который будет при коннекте раздавать айпишник для коннекта и сразу же обрывать соедиенение таким образом освобождая порт, но мне кажется с ДНС лучше будет, к тому же к одному доменному имени можно будет прописать наверно тоже 65к айпишников:)))

← →
Digitman © (2004-04-09 18:29) [30]

> Verg © (09.04.04 18:17) [27]

могу и заблуждаться ... ты уверен ?

← →
Digitman © (2004-04-09 18:32) [31]

> nester © (09.04.04 18:26) [29]

да, вариант без использования ДНС провайдера, пожалуй, лучше будет

← →
Verg © (2004-04-09 18:36) [32]

> Digitman © (09.04.04 18:29) [30]

Да. Я сам частенько путаю connect-accept, особенно по пятницам :)). Вот при connect-е - там да, берется произвольный порт из числа незанятых в специальном диапазоне и назначается на localport этого сокета.

← →
nester © (2004-04-09 18:41) [33]

2Digitman © (09.04.04 18:32) [31]
Почему лучше?
Это отсеется сразу много "лишних" запросов в варианте с ДНС.

← →
Digitman © (2004-04-09 18:47) [34]

> nester © (09.04.04 18:41) [33]

так я и говорю, что лучше не напрягать ДНС !

клиент делает запрос к ДНС, получает некий фикс.адрес
далее по этому адресу клиент делает запрос к серверу, мол, дай актуальный, наиболее свободный в дан.момент интерфейсный адрес ... сервер, подумав куда "развести" данногго клиента, отвечает и тут же рвет коннект ... клиент, получив акт.адрес интерфейса, делает коннект уже к нему, к акт.адресу

← →
nikkie © (2004-04-09 18:52) [35]

а зачем по ip разводить? не проще по нескольким серверным портам?

← →
nester © (2004-04-09 19:30) [36]

:)))) Читай выше.
А мне больше с ДНС все равно нравиться, меньше запросов к серверу, меньше лишних коннектов ...

← →
nikkie © (2004-04-09 19:46) [37]

>:)))) Читай выше.
выше я уже перестал понимать, что именно обсуждают.
проблема в том, что у одного серверного порта есть ограничение на количество клиентов? если так, то решение в точности как в [34], только диспетчер выдает не ip, а номер порта, к которому коннектиться. зачем с ip заморачиваться-то?

← →
nester © (2004-04-09 20:11) [38]

Удалено модератором

← →
Digitman © (2004-04-10 11:42) [39]

> nester © (09.04.04 20:11) [38]

> про базу данных

а это к транспорту имеет отношение ? имхо, абсолютно никакого ..

вопрос по БД задавай в соотв.форуме

← →
Piter © (2004-04-10 13:55) [40]

Digitman (09.04.04 16:37) [6]
а вот максимального числа портов, которые могут быть открыты при каждой отдельной коннекции, с твоими миллионными аппетитами заведомо не хватит) ... нумерация же портов - от 1 до 65к

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

> Что, неужели теперь каждый клиент обязан коннектиться на
> свой ОТДЕЛЬНЫЙ порт?!

Не "на", а "со".

Verg (10.04.04 14:04) [41]

что "со" ?!?!
Сервер никуда не коннектится, это к нему коннектятся! На один порт... о чем вы с Digitman"ом вообще говорите?

я тоже че-т никак не пойму. порт нужен только один. вопросв том, сколько клиентов можно на один порт на вешать.

Piter © (10.04.04 18:46) [42]

> Специфика проги - Держать много открытых коннекшенов TCP
> и обменивать данные между ними.

Где тут про СЕРВЕР?
Ты вообще внимательно читаешь?

> Piter © (10.04.04 18:46) [42]

Умеешь же ты, Piter, "выдергивать" фразы из контекста...

> о чем вы с Digitman"ом вообще говорите?

Лично я, например, вообще не понял - а о чем же говоришь тут ТЫ?

Я от тебя тут не видел ни одного утверждения - одни вопросы с многочисленными восклицаниями и сокрушениями. Возмущение, граничещее с истерикой...
Ты по subj можешь что-нибудь сказать или аргументированно, а глваное спокойно и вдумчиво возразить, приведя свои доводы?

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

Verg (10.04.04 20:24) [44]
Где тут про СЕРВЕР?
Ты вообще внимательно читаешь?

видимо, внимательнее тебя:

>Ето сервер будет:)) который должен с этим справиться:)
>У клиента будет одно соединение - к серверу и все. С клиентом вопросов не возникает. Впрос с сервером,
>хочу прикинуть потянетли все ето киликс или нет?

И ты это сам понял:

>Для сервера, впрочем, это не так важно

Да и Digitman вроде понял:

Digitman (09.04.04 16:41) [7]
в т.ч. и по этой причине в сетях, аналогичных ICQ, работает множество связанных между собою серверов

А вот теперь я не понимаю фразы:

Digitman (09.04.04 16:37) [6]
а вот максимального числа портов, которые могут быть открыты при каждой отдельной коннекции, с твоими миллионными аппетитами заведомо не хватит) ... нумерация же портов - от 1 до 65к

Вот при чем здесь нумерация портов? Какая разница сколько портов? Я так думаю все клиенты будут коннектится на один порт? Или у вас другое мнение?

Verg (10.04.04 20:32) [45]
Ты по subj можешь что-нибудь сказать

не могу. Я не знаю сколько сокетов может открыть максимально NT и Linux. Также я не знаю "на сколько это медленнее будет работать".
Я только заметил, что вы с Digitman"ом, имхо, не о том говорите. Человек же не спрашивает какова нумерация портов в TCP...

> Ето сервер будет:)) который должен с этим справиться:)
> >У клиента будет одно соединение - к серверу и все. С клиентом
> вопросов не возникает. Впрос с сервером,
> >хочу прикинуть потянетли все ето киликс или нет?

Это он сказал в ответ уже на мои уточняющие вопросы ([17], например), как ты внимательный должен был тоже заметить.

> не могу. Я не знаю сколько сокетов может открыть максимально
> NT и Linux. Также я не знаю "на сколько это медленнее будет
> работать".
> Я только заметил, что вы с Digitman"ом, имхо, не о том говорите.
> Человек же не спрашивает какова нумерация портов в TCP...

Так ответь на то, о чем человек спрашивает. Что же ты?

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

Тогда "потрепаться" - это 10-ая дверь направо...

>Verg
тебя я совсем перестал понимать.

давайте поспокойнее. ограничение на количество клиентских подключений к одному серверному сокету должно быть. вопрос только, какое это ограничение - 100, 65000 или 4 миллиарда.

первая попавшаяся ссылка в гугле
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=8&t=000041

Q: When I try to run server application on Window-NT, serversocket can accept upto 65 K client connections & maintain it. But the same application on Solaris only allows 53 client socket connection.

A:This is UNIX, not Java thing.
Type "ulimit -n" at your shell prompt to see how many
open file descriptors can you have at once. I bet you"ll see "64" there. To enable you server app to open 50K connections, you should raise this limit (that can"t be done from the shell)
To do this, you have to find where you got this restrictions up to small number of descriptors and change it (perhaps this is in some scripts in /etc). I don"t know Solaris this well, may be you should ask this in Unix/Linux forum.

итак, видимо общее ограничение для нормальных операционных систем - 65K, реально может получиться чуть меньше. может потребоваться какая-то настройка OS. от выбора языка C/Kylix это никак не зависит.

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

> nikkie © (10.04.04 22:02) [50]

Если говорить про Windows, то максимальное количество открытых сокетов (в сумме и клиенты и серверы с присоединенными сокетами) для одного процесса можно увидеть в структуре WSAData после WSAStartup.

При установлении исходящего соединения (клиент, connect), кроме этого ограничения есть еще одно - количество свободных на данный момент номеров портов из "временного диапазона", т.к. при установлении исходящего соединения ядро (или приложение само)обязано присвоить какое-то уникальное значение localport для сокета.
При входящем соединении (сервер, accept) - образуется новый сокет и их количество в сумме с уже существующими не может превосходить установленный лимит.
Все.
Вопрос для сервера заканчивается только этим "лимитом" - сокетов на процесс.

>максимальное количество открытых сокетов (в сумме и клиенты и серверы с присоединенными сокетами) для одного процесса можно увидеть в структуре WSAData после WSAStartup.
unsigned short iMaxSockets
Retained for backward compatibility, but should be ignored for Windows Sockets version 2 and later, as no single value can be appropriate for all underlying service providers.

При установлении исходящего соединения (клиент, connect) ... присвоить какое-то уникальное значение localport для сокета.
это понятно. но давай не будем мешать все в одну кучу. проблемы клиента нас не волнуют, мы говорим про сервер.

Вопрос для сервера заканчивается только этим "лимитом" - сокетов на процесс.
ок. предполагаем, что все присоединеные сокеты обслуживаются одним процессом. какой это лимит? те самые 65K? значит диспетчер должен разводить на разные порты, каждый из которых обслуживается отдельным процессом. если возможно получить 50K сокетов на процесс, то достаточно 20 серверных сокетов и процессов, их обслуживающих, чтобы поддержать миллион подключений.

> ок. предполагаем, что все присоединеные сокеты обслуживаются
> одним процессом. какой это лимит? те самые 65K? значит диспетчер
> должен разводить на разные порты, каждый из которых обслуживается
> отдельным процессом. если возможно получить 50K сокетов
> на процесс, то достаточно 20 серверных сокетов и процессов,
> их обслуживающих, чтобы поддержать миллион подключений.

Нет не 65к. Для Winsock2 - это вообще, как я понял, ограничивается чисто системными ресурсами.
Их обрабатывать - для поддержки каждого клиента все равно надо хоть сколько-нибудь связанной именно с ним памяти управляющей структуры+размеры буферов как минимум. Сколько думаешь кил на клиент ? - Кил 8-10 минимум (вместе с буферами). Плюс поток. Один для каждого? Да хоть один на несколько (сотен?).
Память процесса сколько? Реально доступной? 2 гига?
Поделим хотя бы на миллион (соединений)? :))

nikkie (10.04.04 22:46) [52]
ок. предполагаем, что все присоединеные сокеты обслуживаются одним процессом. какой это лимит? те самые 65K?

о, nikkie как всегда все понял, говорит по делу.

Если честно - не думаю, что лимит в 65k. Неужели он равен количеству возможных портов в TCP? Я знаю, что в 9x маскимальное количество сокетов было 255, причем это ограничение не на процесс, а на систему вообще, на все процессы.
В NT это значение явно больше. Намного больше. Я даже думаю, что это зависит от поставки, в NT server этот лимит, наверняка, больше, чем в NT prof и home

Я так считаю, что разводить на разные порты вовсе не обязательно - это можно делать запуском дополнителных процессов с передачей им дублицированных дескрипторов присоединенных (полученных accept-ом) сокетов и закрытием их же в "слушающем процессе". К примеру, каждой 500-ке принятых соединений - новый процесс. Те процессы сами группируют эти сокеты по потокам обработки, например, по 60-100 штук.

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

Polevi (10.04.04 21:48) [48]
смоги, узнай и возмущайся аргументировано

по-моему, ты не по адресу вмешался. Я и не говорил, что знаю ответа на вопрос. Я просто сделал замечание...
Или если я знаю, что человек говорит не то, но сам ответа не знаю - мне запрещается высказываться?

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

а вот интересный FAQ, имхо
http://www.opennet.ru/base/dev/server_way.txt.html

Но,.... я бы не рискнул "валить" это все на один комп.
это точно...

А что будет быстрее работать при написании приложения для сети? Найти похожие ветки