На Delphi Studio вы можете найти и скачать исходники, примеры, компоненты, книги, учебники, статьи по Delphi и Pascal

УЧИМСЯ ИСПОЛЬЗОВАТЬ WINSOCK. ЧАСТЬ II.

УЧИМСЯ ИСПОЛЬЗОВАТЬ WINSOCK. ЧАСТЬ II.

(подключение, передача и прием данных. многопоточность.)

ПРЕДИСЛОВИЕ

Как и обещал в первой статье, сейчас будут рассмотрены:

- Функции подключения к удаленному серверу и ожидание входящих подключений

- Передачи и приема данных.

- Организация многопоточности клиента и сервера.

- Будут рассмотрены вопросы, связанные с пингованием серверов и таймаута для подключения.



ПОДКЛЮЧЕНИЕ

Предположим что у нас уже был создан сокет sock:TSOCKET и настроены все параметры caddr:sockaddr_in. (читайте первую статью)

Для осуществления подключения к другому компьютеру, необходимо использовать функцию connect

function connect( const s: TSocket; const name: PSockAddr; namelen: Integer): Integer; stdcall;


Первым параметром передается созданный сокет

Вторым – адрес структуры sockaddr_in

Третьим – размер структуры sockaddr_in в байтах.

При удачном подключении будет возвращено число 0.

Для распознания кода ошибки необходимо использовать функцию WSAGetLastError которая возвращает код ошибки. Коды ошибок можно посмотреть в MSDN


Но на практике важны следующие значения:

WSAECONNREFUSED – сервер отверг попытку подключения

WSAENETUNREACH – сеть недоступна

WSAETIMEDOUT – не удалось подключить к серверу в установленный промежуток времени(банальный timeout).

На практике это выглядит как





Важно заметить, что по умолчанию в Windows XP/2003 время таймаута для коннекта стоит 20-45 секунд. В некоторых случаях это очень неудобно когда, к примеру используется работа со списками прокси серверов и при попадании на мертвый сервер идет большая пауза, по этому для того, чтобы учитывать такие ситуации (когда они критически важны) необходимо применять различные способы. Каждый из этих способов имеет свои плюсы и минусы. В основе этого лежат 3 способа

1) предварительное пингование сервера – очень удобно чтобы сразу определить доступен сервак или нет. Но есть минусы – не все серваки отвечают на пинг, а также пинг не может свидетельствовать об открытости нужного порта.

2) запуск отдельного потока и в нем выполнение действий, и при истечении таймаута закроется сокет и прибьется поток. – отнимает ресурсы очень сильно, но зато в его помощью можно задать таймаут на выполнения блока функций. К примеру, функция которая получает данные от клиентов или от сервера может завершить свою работу по истечению таймаута, независимо от того, на чем остановилась работа.


Алгоритм выглядит примерно так:



В основной программе создается поток через CreateThread

И затем дескриптор потока передается функции WaitForSingleObject, в которой как раз и задается таймаут. Если функция завершилась с кодом WAIT_TIMEOUT, значит, сработал таймаут, и тогда необходимо самому закрыть сокет (CloseSocket) и завершить поток через TerminateThread


Также аналогом данного метода может быть применение таймеров. В таком случае делается наоборот всё. Т.е. перед выполнение работы с сетью запускается таймер – settimer. И в его обработчике уже делаются все действия связанные с таймаутом. Но как видно – метод очень сильно тратит ресурсы.

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



Рассмотрим 1 и 3 способ более подробно т.к. они более актуальны сейчас.



ВРЕМЕННЫЙ ПЕРЕВОД В НЕБЛОКИРУЕМЫЙ РЕЖИМ





ПРЕДВАРИТЕЛЬНОЕ ПИНГОВАНИЕ СЕРВЕРА

Пингование будем осуществлять через функции icmp.dll



Теперь если нам необходимо проверить жив сервак или нет мы может использовать эту функцию так:



первым параметром задается IP адрес сервера. (доменное имя нельзя)


вторым – время ожидания ответа на пинг в миллисекундах.

т.е. 3000 – 3 секунды.



ОЖИДАНИЕ ВХОДЯЩЕГО ПОДКЛЮЧЕНИЯ

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

1) bind – ассоциирование локального адреса с сокетом.

function bind( const s: TSocket; const addr: PSockAddr; const namelen: Integer ): Integer; stdcall;

первый параметр – сокет


второй – ссылка на структуру sockaddr_in в которой необходимо указать порт на котором мы будем ожидать подключение и IP адрес (для того чтобы привязать к определенному интерфейсу)

третий – размер структуры sockaddr_in

При удачном выполнении функция вернет 0

Как видно это функция очень похожа connect.

Также при ошибке можно воспользоваться функцией WSAGetLastError

Самой распространенной ошибкой является WSAEADDRINUSE.


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



2) listen – переводит сокет в режим ожидания входящих подключений.

function listen(s: TSocket; backlog: Integer): Integer; stdcall;

первый параметр – сокет

второй – максимальная длинна очереди клиентов, которые запросили подключение, но еще небыли подключены.



3) accept - извлекает из очереди ожидающих подключений первое, затем создает новый сокет и возвращает его дескриптор и некоторое описание клиента. Размер этой очереди как раз и устанавливается в функции listen.




function accept( const s: TSocket; var addr: TSockAddr; var addrlen: Integer ): TSocket; stdcall;

первый параметр – сокет

второй – адрес структуры sockaddr_in куда будет помещена информация о клиенте.

третий – размер структуры sockaddr_in

При удачно завершении функция возвращает дескриптор сокета. При неудачно - INVALID_SOCKET




В сокет, который возвращает accept, можно использовать для приёма и передачи информации.

Как я уже говорил ранее в addr будет возвращена информация о клиенте. Нам будет важна только:

addr.sin_port – порт с которого было подключение

addr.sin_addr – ip клиента в двоичном формате. Для преобразования в строковой формат используется функция inet_ntoa. Т.е. ipchar; ip:=inet_ntoa(addr.sin_addr);




т.е. основная структура будет выглядеть так:




Хотя на деле лучше всего конструкцию while true do заменить на

while переменаня do чтобы можно было прерывать бесконечный цикл



ПОЛУЧЕНИЕ ДАННЫХ

Вот мы и добрались до приема данных с сокета.

Это самое простое что может быть. Для получения данных используется функция

recv. Функция может применять и для TCP и для UDP соединение. Но всё же желательно использовать её только для TCP


function recv(s: TSocket; var Buf; len, flags: Integer): Integer; stdcall;

первый параметр – сокет

второй – адрес буфера куда будут закинуты данные

третий – размер этого буфера.

Flags – специально опции чтения. Нам они особо не важны, по этому будем ставить его = 0

При неудаче функция возвращает значение SOCKET_ERROR

Если функция вернула значение = 0 – это свидетельствует о том, что клиент/сервер разорвал соединение и дальнейшее чтении уже ненужно и требуется лишь закрыть сокет.


Все остальные значение – это размер считанных данных. Но в любом случае это кол-во не может быть больше чем размер буфера указанный в len.





Для чтение данные передаваемых по UDP протоколу используется функция recvfrom

function recvfrom(s: TSocket; var Buf; len, flags: Integer; var from: TSockAddr; var fromlen: Integer): Integer; stdcall;

Она ничем не отличается от recv за исключением последних двух параметров.


from: TSockAddr – адрес структуры в которую будет помещена информация о том, кто прислал данные (PORT и IP).

fromlen: Integer – размер этой структуры.



ПОСЫЛКА ДАННЫХ

Для посылке данных используется функция send и sendto.Подробно описывать данные функции я не буду, потому что они полностью аналогичны recv и recvfrom за одним 2-мя лишь исключениями:


- функции возвращают кол-во посланных, а не принятых данных

- в sendto в поле addrto (аналог from из recvfrom) указывается адрес и порт того компьютера кому предназначаются эти данные.



P.S. Если вы клиент и посылаете данные по UDP протоколу, то следует учесть следующее:

1) Вы можете не делать connect а сразу после создания сокета слать данные через sendto указывая в нем адрес того, кому предназначаются данные


2) Если вы используете connect то для посылке данных можно использовать функцию send. И тогда ip и порт сервера будут браться из структуры, которая была передана функции connect



МНОГОПОТОЧНОСТЬ КЛИЕНТА

Организация многопоточной работы для отправки данных особо ничем не отличается об однопоточной работы, просто весь код работы с сетью оформляется в виде отдельной процедуры(за исключением функции WSAStartup потому как её нужно делать только 1 раз), которая запускается в потоке через функцию CreateThread. Единственное о чем хочется упомянуть так это только о том, что при работе с глобальными переменными желательно делать простейшую синхронизацию. Выглядеть это будет примерно так:




Thread – это массив в который мы будем записывать дескрипторы созданных потоков, чтобы потом при необходимости можно было завершить их через TerminateThread

Для более сложной синхронизации лучше применять критические секции.

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




МНОГОПОТОЧНОСТЬ СЕРВЕРА

Показанный выше код серверной части одновременно может обрабатывать только 1 запрос клиента. А это очень сильно снижает скорость работы. Для того чтобы организовать многотопочную обработку клиентов необходимо после получения сокета от функции accept, передать его созданному потоку. Программно это будет выглядеть так:





Как видно из кода, после получения дескриптора сокета мы запускаем поток, и передаем в виде параметра, этот дескриптор.



ОБРАТИТЕ ВНИМАНИЕ 1 – поток должен быть завершен командой ExitThread(0) т.к. это является более корректным завершением.

ОБРАТИТЕ ВНИМАНИЕ 2 – очень важная деталь, о котором многие забывают. После создания потока мы получаем дескриптор потока. Но даже при завершении потока через ExitThread, всё равно дескриптор остается открытым. Со временем это приводит в утечки памяти, а также разного рода тормозам, когда невозможно запустить новые потоки.


Т.к. мы не собираемся завершать поток насильно, то нам этот дескриптор не нужен и по этому мы его сразу закроем через CloseHandle.



Ну вот всё ))

(С) SLESH 2009