Серверное окончание интерфейса WinSock в библиотеке визуальных компонентов реализовано в виде класса TTCPServer. Между TTCPServer и его предком TCustomTCPServer нет практически никаких различий, разве что TTCPServer ряд унаследованных методов опубликовал в секции published. Сервер TTCPServer -полноценный невизуальный компонент, который вы обнаружите на странице Internet палитры компонентов Delphi. На его базе достаточно легко реализовать элементарный сервер WinSock для работы в сетях Интернет и интранет.

На первой стадии разработки проекта сервера программист принимает решение о режиме блокировки, в котором будет работать сервер. Выбор осуществляется свойством:

property BlockMode : TServerSocketBlockMode; //по умолчанию bmThreadBlocking type TServerSocketBlockMode = (bmBlocking, bmNonBlocking, bmThreadBlocking);

В нашем распоряжении всего три режима, два из которых классические. bm-Blocking - синхронный режим, часто называемый блокирующим, т. к. в нем операции ввода/вывода не возвращают управление вызвавшему их приложению до окончания своего выполнения. Таким образом, работа приложения приостанавливается на неопределенное время, что не очень приятно.

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

Третий режим - фирменный способ Delphi по работе с сокетом. В режиме bmThreadBlocking процесс сбора заявок на обслуживание происходит в рамках потока TServerSocketThread, который мы станем называть потоком управления, а для непосредственного обслуживания вошедшего в соединение клиента применяется отдельный поток - экземпляр класса TClientSocketThread (поток обслуживания). Таким образом, «неудобные» синхронные операции осуществляются в фоновом режиме, благодаря чему не блокируется выполнение приложения в целом.

ОПоскольку наиболее оптимальным режимом блокировки является bmThreadBlocking, то дальнейший материал в первую очередь нацелен на описание работы сервера именно в этом режиме.

Сам по себе экземпляр класса TTCPServer даже после вызова конструктора еще не является сокетом в полном смысле этого слова. Пока это только пустая оболочка. Компонент TTCPServer превращается в сокет только после вызова унаследованного от TBaseSocket метода Open() . Именно в нем посредством обращения к методу Win32 API Socket() создается экземпляр сокета-сервера. Новорожденный сокет сразу же интегрируется в любезно предложенный нами каркас VCL - компонент TTCPServer.

Впрочем, все это было предусмотрено еще на уровне класса TBaseSocket, но на данном этапе нас больше интересуют заслуги его потомка. Забегая вперед, скажу, что он нас не разочарует. TCustomTCPServer() не остался в стороне и внес в метод Open() некоторые усовершенствования. При этом им эгоистично учитывался тот факт, что он представляет интересы серверного окончания интерфейса WinSock. Итак, кроме физического создания сокета в рамках Open() :

1. Автоматически заполняется локальный адрес созданного серверного со-кета.

2. Вызывается метод Win32 API listen(), который переводит сервер в режим прослушивания канала. Если свойство BlockMode установлено в bmThread-Blocking, то прослушивание проводится в отдельном потоке, которым управляет экземпляр класса TServerSocketThread.

Такие подробности этапов выполнения Open() вносят ясность в череду событий, которыми они сопровождаются. Сразу после создания сокета-сервера вызывается событие:

property OnCreateHandle: TSocketNotifyEvent;

Затем, до того как сокет приступит к прослушиванию, инициируется событие:

property OnListening: TNotifyEvent;

Кстати, косвенным признаком того, что сервер в текущий момент находится в состоянии прослушивания, служит значение true, возвращаемое свойством:

property Listening: Boolean; //только для чтения

К последствиям вызова метода Open() также относится незамедлительный переход свойства Active в состояние true.