Синхронное или асинхронное соединение

← →
Romul (2002-01-22 14:47) [0]

Люди, я вообще-то программированием под СУБД занимаюсь, но тут надо было и я SNPP-серверочек небольшой сделал. Суть такая, что SNPP протокол, это что-то типа SMTP (т.е. команда-ответ сервера-команда и т.д.). Я сделал все это через ClientSocket (SNPP-сервер стоит в другой конторе и меня не особо волнует). Все действия я выполняю после события onClientSocketRead (и все это асинхронно делается, т.е. nonBlocking). Я вот думаю (все нормально работает) правильно ли я асинхронно все это сделал? Может синхронно лучше? Объясните в каких случаях какой режим используется (синх или асинх)? Ну ламер я (пока) в этой области.

← →
Digitman (2002-01-22 15:06) [1]

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

Синхронный режим (в случае с TServerSocket это - thread-blocking режим, т.е. мультипоточный с применением блокирующих WinsockAPI-вызовов на уровне потоков) хорош тем, что обработка сервером одновременных кл.запросов происходит параллельно, в разных ьпотоках, каждый из которых является индивидуальным транспортным потоком отдельного кл.соединения.
В первую очередь, такой режим нужен, когда время_ожидания_ответа значительно (к примеру, клиент запросил у сервера НД, формирование которого сервер выполняет запросом к СУБД и факт.время выполнения запроса относительно велико). Если бы сервер обрабатывал такие "навороченые" запросы последовательно, клиента за клиентом, в единственном кодовом потоке, то вместе с текущим клиентом прочие клиенты так же ждали бы, пока сервер обслужит его запрос и очередь обслуживания дойдет до них.
К слову сказать, все современные промышленные SQL-серверы являются мультипоточными (технология SuperServer), и обработка кл.запросов в них выполняется параллельно, в различных потоках, использующих, в т.ч. и как правило, блокирующие API-вызовы транспортного и других уровней

← →
Romul (2002-01-22 15:15) [2]

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

← →
Digitman (2002-01-22 15:42) [3]

Протокол инф.обмена между сервером и клиентом здесь совершенно ни при чем. Это лишь соглашения между обменивающимися информацией сторонами о форматах транслируемых сообщений.
Тот же POP-сервер, прежде чем выдаст клиенту запрошенные им в POP-формате данные, проделывает, как правило, гигантскую работу по поиску в своих БД входящих почтовых сообщений, адресованных тек.клиенту. И все это время, с момента подачи запроса, клиент ждет. И все остальные клиенты тоже будут ждать, пока сервер обслужит клиентов, стоящих впереди в очереди запросов, если сервер - однопоточный.

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

И еще. "Блокирующий" режим и "мультипоточный" режим - вещи, в принципе, различные, но одновременно тесно связанные в настоящих ,проф-но выполненных, распределенных инф.системах.

Синхронное или асинхронное соединение Найти похожие ветки