Синхронне або асинхронне з'єднання

Синхронне або асинхронне з'єднання

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

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

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

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

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

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

Пам'ять: 0.73 MB
Час: 0.04 c

Схожі статті