Блокирующие сокеты + потоки

[VirtUX]

Использую TUDPBlockSocket для общения клиента и сервера.
Клиентов более 100.
В будущем планируется организовать суб-сервера группирующие и обслуживающие подгруппы клиентов, а так же сбрасывающие итоги на мастер-сервер.
На клиенте все просто:
- отправили запрос;
- получили квитанцию о доставке запроса;
- перешли в режим ожидания ответа;
- получили ответ.
На сервере:
Планирую
- в отдельном потоке читать из сокета (тут же отправив квитанцию о получении запроса), и через критическую секцию (КС_БВЗ) сохранять в буфер входящих запросов;
- в другом отдельном потоке через КС_БВЗ читаем запросы, и для каждого отдельного запроса порождаем поток обработчик;
- поток обработчик результат сохраняет через критическую секцию (КС_БГО) в буфер готовых ответов;
- в третьем отдельном потоке через КС_БГО читаются ответы и через сокет отправляются клиенту.

Что мне хотелось бы узнать:
Как правильно организовать доступ к единственному сокету из двух потоков, которые: один читает из него, другой отправляет ответы через него?
Как мне это видится:
Через критическую секцию организовать доступ к сокету. Но если я в один момент отправляю ответ, и на сокет пришел запрос - никакого казуса не выйдет?
P.S. Если можно, то объясните подробно: что конкретно блокируется и в какой момент при работе с сокетом? То, что основной процесс переходит в ожидание - это понятно, но в моем случае как это выглядит?
Спасибо!

[hinst]

TUDPBlockSocket
Это в какой библиотеке такой класс?
"Блокирующие сокеты" это когда при вызове метода Send, например, управление вызывающей процедуре передаётся только после того, как данные будут отправлены. "Неблокирующие сокеты" в таком случае это такие, которые при вызове метода Send, например, возвращают управление сразу, а отправлять данные начинают в каком-нибудь отдельном потоке или ещё как-нибудь, но часто это реализовано именно так, что "неблокирующие сокеты" создают ещё один поток (или много?), так что вы сейчас контроллите руками то, что они делают "сами". Короче если я ещё не сошёл с ума, слово "блокирующие" сокеты означает то, что они не возвращают управление вызывающей процедуре пока не отправят или не примут данные, смотря какой метод вызвали, больше в них ничего такого не блокируется

[VirtUX]

спасибо!
TUDPBlockSocket - это класс в модуле blcksock из пакета synapse. Использую, т.к. там много чего реализовано часто используемого, и... вродебы, не глючит

[hinst]

Как правильно организовать доступ к единственному сокету из двух потоков, которые: один читает из него, другой отправляет ответы через него?
Как мне это видится:
Через критическую секцию организовать доступ к сокету. Но если я в один момент отправляю ответ, и на сокет пришел запрос - никакого казуса не выйдет?

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

[VirtUX]

Меня берут сомнения вот в чем: если во время незавершенного чтения из сокета, ОС отдаст процессорное время потоку, который начнет отправлять через сокет ответ (или наоборот), то недоотправленные или недополученные данные в следующем переключении очереди потоков доотправятся/дополучатся? Мне интересно: ОС блокирующему сокету даст завершить чтение или отправку данных? Или выделенное процессорное время закончившись оборвет передачу/чтение?

[SeZuka]

Или выделенное процессорное время закончившись оборвет передачу/чтение?

Если бы так работала ОС, то мы бы никогда не увидели нормального изображения на экране и не услышали бы звуков из колонок и не было бы связи между компьютерами.
Вы бы лучше подумали о другой проблеме, ваша программа может повиснуть, из-за ожидания блокирующим сокетом данных, которые где-то затерялись в сети.

[VirtUX]

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

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

Если бы так работала ОС, то мы бы никогда не увидели нормального изображения на экране и не услышали бы звуков из колонок и не было бы связи между компьютерами.

Спасибо, - утешили Значит долой критику на сокет.
Еще раз всем спасибо за разъяснения!

[Kemet]

Где-то была переводная статья (возможно на хабре), что вместо организации конкуренции за сокеты и разгребания проблем, лучше открывать столько сокетов, сколько нужно для разных потоков. Хотя в статье речь больше шла о производительности, тем не менее, думаю, в случае ТС такой подход также подойдёт.

[VirtUX]

открывать столько сокетов, сколько нужно для разных потоков

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

[GrayEddy]

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

[VirtUX]

на одно новое соединение создается новый тред

в принципе я так и реализую:

в другом отдельном потоке через КС_БВЗ читаем запросы, и для каждого отдельного запроса порождаем поток обработчик;