vavan,

Да у нас на предыдущих работах сетевой модуль занимал пару тысяч строк. Притом все прекрасно работало асинхронно, не в тыщу потоков. Не знаю, правда, способны ли 1М соединений поддерживать, но тем не менее. Я не думал, что это вынудит ребят пойти в обиженку «знаю, но не скажу».

Не факт, что своё. А может и своё. Мне интересно, как это делается, не факт, что я буду реализовывать. А может буду

Все тут расхваливают RTC. Может его возьму. Может стандартный Indy для начала. Как поступить в итоге - я решу сам. Мой вопрос в методологиях, а не в том, что мне делать

чччД__,

Если бы кто-то платил за такую СУБД - я бы писал )

YuRock,

У меня есть библиотека для рассчета путей. Логистическая библиотека может быть на борту )

В общем посоветовался тут с одним человеком

Он говорит, что менеджмент сессий и обработка данных по сокетам происходит в одном потоке
Хоть 5 соединений, хоть миллион

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

чччД__,

С Мининым и Пожарским ты конечно загнул. Но Susanin DB как название мне нравится. Хоть и не очень удачно скажется на имидже )

P.S. а вообще для самой быстрой DB нужна собственная операционная система, чтобы напрямую и по-максимуму использовать возможности железа. Но это лишь мечты :)

чччД__,

Ну дело не только с RAW разделами дисков
Нет, например, возможности создать такую критическую секцию, внутри которой поток гарантированно не застынет
В Винде полно потоков, которые выполняют какую-то левую работу

Да и в режиме ядра наверняка можно придумать какие-то плюшки

P.S. но всё это лирика