Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2004.05.30;
Скачать: CL | DM;

Вниз

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

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



Страницы: 1 2 вся ветка

Текущий архив: 2004.05.30;
Скачать: CL | DM;

Наверх




Память: 0.59 MB
Время: 0.025 c
6-1081490934
Orc
2004-04-09 10:08
2004.05.30
Проверить наличие веб-сервера


14-1084430929
Kerk
2004-05-13 10:48
2004.05.30
RTFM


3-1083912884
TransparentGhost
2004-05-07 10:54
2004.05.30
Перенос базы IB6.x ->> FB1.5 - есть ли где грабли?


3-1084275020
Gennadiy
2004-05-11 15:30
2004.05.30
Проблема с условием в хранимой процедуре


3-1084339328
student__
2004-05-12 09:22
2004.05.30
срочно нужен обзор ADO