Каморка

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

Так не держи соединение открытым. Или кто заставляет?

spavel писал(а):Т.е. сокеты использовали ? а как боролись с лимитами по количеству подключений на 1 порт ?

в смысле ?

* перевод с транслита

в смысле ?

никто не заставляет открытыми держать

spavel писал(а):Т.е. сокеты использовали ? а как боролись с лимитами по количеству подключений на 1 порт ? Я тоже думал о сокетах (тем более уже есть пару апликаций через них бегущих), но меня смущает "ограниченность"

Какие такие лимиты? На сервере???

Как же это бедные веб сервера все через один-одинешенек 80-й порт работают то???

-Maxim

spavel писал(а):в смысле ?

никто не заставляет открытыми держать :)

в смысле какие именно лимиты ?

* перевод с транслита

одна проблема - влияние качества связи на нормальную работу. В оригинале TCP/IP расчитанно на проволочные связи. При изменении латенси сетки скорость и надежность резко падают.

сам сервер для TCP/IP сокетов тоже дело грустное. Мне пришлось писать сервер лет 5 назад. Ни один из готовых компонентов нам не подходил - поэтому делали свой. при количестве подключений больше 256 начинались проблемы (нас не парило - у нас до 25 конектов было, поэтому не долбались) А контролировать все буфера, очереди и прогонять их с разными приоритетами вообще была морока. Я после этого к сокетам недображелательно отношусь...

хотя возможно глубоко не прав и за последние несколько лет что-то изменилось...

spavel писал(а):одна проблема - влияние качества связи на нормальную работу. В оригинале TCP/IP расчитанно на проволочные связи. При изменении латенси сетки скорость и надежность резко падают.

конечно, не падают. не говоря о том, что бы резко

сам сервер для TCP/IP сокетов тоже дело грустное. Мне пришлось писать сервер лет 5 назад. Ни один из готовых компонентов нам не подходил - поэтому делали свой. при количестве подключений больше 256 начинались проблемы (нас не парило - у нас до 25 конектов было, поэтому не долбались) А контролировать все буфера, очереди и прогонять их с разными приоритетами вообще была морока. Я после этого к сокетам недображелательно отношусь...

хотя возможно глубоко не прав и за последние несколько лет что-то изменилось...

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

один из лучших сушествуюших summaries по теме -
http://www.kegel.com/c10k.html

советую его внимательно прочитать и прочувствовать прежде
чем начинать "делать свой компонент"

на коленке пишетcя сервер, который держит до 10к клиентов. в
одном треде. после 50к могут начатcя проблемы, но вто уже
будет на уровне ядра. чисто reference numbers to keep in mind :)

Линуксом не пользуемся... и клиенты наши не хотят.

spavel писал(а):Линуксом не пользуемся... и клиенты наши не хотят.

Вот он, источник всех ваших проблем

spavel писал(а):Линуксом не пользуемся... и клиенты наши не хотят.

причем здесь линукс.

на виндовс есть обычный select, которого достаточно до 1024 клиентов,
есть IO Completion Ports, есть WSASetEvent + WaitForMultipleObjects, etc ..

есть все что нужно. даже документация есть :)

Cm'n данный подход хорош если нагрузка большая. А так нафиг надо, треды легко держат нагрузку исчисляемую десятками..., я те больше скажу пресловутый ремблер до 2000 года и вовсе на форках работал и ничего россию тянул тут от задачи все таки зависит...

А подход к обработке может быть легко смешанным: сервер шлет на клиента кратенькое уведомление, а дальше клиент решает связываться ему с сервером или нет и когда и поскольку и зачем.

aissp писал(а):Cm'n данный подход хорош если нагрузка большая. А так нафиг надо, треды легко держат нагрузку исчисляемую десятками...,

вто когда они pthreads и имеют cancellation points, а не как в виндовсах,
когда thread, сидяший в blocking call, можно только из БФГ оcтреливать

от задачи зависит - никто не спорит, но а thread-per-IO (без completion
ports скажем) - вто конечно просто, но hugely wasteful. и если количество
активных IO тредов больше чем количество CPU, то контекстные свитчи
могут в легкую убить performance.

я те больше скажу пресловутый ремблер до 2000 года и вовсе на форках работал и ничего россию тянул :) тут от задачи все таки зависит...

ну он же ее нe на одной машине тянул ?

О да конешно не на одной, чтобы так сказать подчеркнуть свой понт приходицца иногда не то что привирать но не говорить все факты:)

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

aissp писал(а):О да конешно не на одной, чтобы так сказать подчеркнуть свой понт приходицца иногда не то что привирать но не говорить все факты:)

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

Угум-с, особенно когда надо не просто байты в сокеты пропихивать, а к DB коннектится или там файлы читать/писать, это тоже все конечно можно nonblocking сделать, тока в этом случае время разработки/отладки в средней команде будет стремится к восмерке на боку Какая уж там в попу экономия на преключениях контекста...
Вона скока вебсайтов на Apache бегают, и ничего...