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

СОЗДАНИЕ СЕТЕВОЙ ИГРЫ “КОСТИ” Выполнили: Студенты группы ЭиУ-423 Захезин С.М. Капацина Д. Давидович И. Проверил: Сартасов Е.М. Челябинск, 2006 Аннотация Создание сетевой игры «Кости». Игра ведется до 21 очка, работа сделанна на 5 протоколах. Введение Правила игры Один из игроков является сервером, другой – клиентом.

Для начала игры необходимо выбрать протокол, по которому будет установлена связь. Длительность игры зависит от набранных очков и желания играков. Протоколы IPX Протокол IPX предоставляет возможность программам, запущенным на рабочих станциях, обмениваться пакетами данных без подтверждения. В сети Novell NetWare наиболее быстрая передача данных при наиболее экономном использовании памяти реализуется именно протоколом

IPX. Протоколы SPX и NETBIOS сделаны на базе IPX и поэтому требуют дополнительных ресурсов. Формат пакета IPX Формат передаваемых по сети пакетов представлен на рис. 2. Рис. 2. Структура пакета IPX Пакет можно разделить на две части - заголовок и передаваемые данные. Все поля, представленные на рис. 2, кроме последнего (Data), представляют собой заголовок пакета. Заголовок пакета выполняет ту же роль, что и конверт обычного письма - там располагается адрес назначения,

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

в компьютере IBM-370 (серия ЕС ЭВМ) Работа с драйвером IPX/SPX Первое, что должна сделать программа, желающая работать в сети с протоколом IPX или SPX проверить, установлен ли драйвер соответствующего протокола. Затем необходимо получить адрес вызова этого драйвера - точку входа API (Application Programm Interface - интерфейс для приложений).

В дальнейшем программа вызывает драйвер при помощи команды межсегментного вызова процедуры по адресу точки входа API драйвера IPX/SPX. Схема "клиент-сервер" Обычно в сети одна из рабочих станций принимает запросы на выполнение каких-либо действий от других рабочих станций. Так как станция обслуживает запросы, она называется сервером (serve - обслуживать, server - обслуживающее устройство). Выполнив запрос, сервер посылает ответ в запросившую станцию, которая

называется клиентом. В сети может быть много серверов и много клиентов. Одни и те же клиенты могут посылать запросы разным серверам. Говоря более строго, сервером или клиентом является не рабочая станция, а запущенная на ней программа. В мультизадачной среде разные программы, запущенные одновременно на одной и той же рабочей станции могут являться и клиентами, и серверами. Программа-сервер, выполнив очередной запрос, переходит в состояние

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

Для того, чтобы создавать программы-серверы и программы-клиенты, нам необходимо научиться выполнять две задачи: • инициализацию сервера и клиента; o прием и передачу пакетов данных. Инициализация сервера и клиента Для инициализации программ сервера и клиента, работающих на базе IPX, недостаточно убедиться в наличии соответствующего драйвера и получить точку входа в его API. Необходимо выполнить некоторые подготовительные действия для того, чтобы программа могла принимать

и передавать пакеты данных. Прежде всего необходимо, чтобы программа-сервер или программа-клиент идентифицировали себя в сети при помощи механизма сокетов. Динамически распределяемые сокеты выдаются программам как бы во временное пользование (на время их работы) по специальному запросу. Перед началом работы программа должна запросить сокет у протокола IPX, а перед завершением - освободить его. При реализации схемы обмена данными "клиент-сервер"

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

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

Все свои запросы на прием и передачу пакетов они направляют драйверу IPX (программа ipx.exe или ipxodi.exe), который, в свою очередь, обращается к драйверу сетевого адаптера. Для приема или передачи пакета прикладная программа должна подготовить пакет данных, сформировав его заголовок, и построить так называемый блок управления событием ECB (Event Control Block). В блоке ECB задается адресная информация для передачи пакета, адрес самого

передаваемого пакета в оперативной памяти и некоторая другая информация. Подготовив блок ECB, прикладная программа передает его адрес соответствующей функции IPX для выполнения операции приема или передачи пакета. Функции IPX, принимающие или передающие пакет, не выполняют ожидания завершения операции, а сразу возвращают управление вызвавшей их программе. Прием или передача выполняются сетевым адаптером автономно и асинхронно

по отношению к программе, вызвавшей функцию IPX для передачи данных. После того, как операция передачи данных завершилась, в соответствующем поле блока ECB устанавливается признак. Программа может периодически проверять ECB для обнаружения признака завершения операции. TCP/IP Рассмотрим работу семейства протоколов TCP/IP при обмене данными между двумя процессами telnet, выполняющимися

на двух разных хостах, входящих в две разные сети, соединенные посредством маршрутизатора. Работа протокола TCP Протокол верхнего уровня (приложений/процессов) разделяет данные на кусочки (это процесс называется инкапсуляцией) и каждому кусочку добавляет заголовок. То, что получается в результате, называется TCP-сегментом. TCP-сегмент Заголовок TCP-сегмента Данные Модули протокола

TCP обмениваются TCP-сегментами. Протокол TCP обеспечивает надежную дуплексную передачу с предварительной установкой связи и с разрывом соединения. Надежная – осуществляется контроль получения данных. Сегмент, на данные которого не пришло подтверждения через определенное время, посылается снова. Дуплексная – значит, передача в две стороны, туда и обратно, передача только в дону сторону называется симплексной. Формат заголовка TCP-сегмента Формат заголовка

TCP-сегмента (заголовок состоит из 32-битных слов): 0 (бит) 4 8 12 16 20 24 28 31 Source Port Destination Port Sequence Number Acknowledgement Number Offset Reserved Flags Window Checksum Urgent Point Options Padding • Source Port и Destination Port – это адреса процессов (отправителя и получателя соответственно).

Грубо говоря, это просто числовые идентификаторы, которые присвоены процессам-протоколам верхнего уровня. Некоторые протоколы верхнего уровня имеют стандартные значения номеров портов: Номер порта Процесс 20 ftp-data (передача данных по ftp) 21 fpt (команды) 23 telnet 25 smtp 70 gopher 80 www-http и т.д. • Sequence Number – порядковый номер первого октета сегмента в потоке данных. • Acknowledgement Number – количество полученных октетов данных •

Window – сколько октетов адресат готов принять • Offset – начало данных сегмента • Flags – управляющие флаги, используемые для установки и разрыва связи, для подтверждения получения данных, для передачи экстренных данных. • Checksum – контрольная сумма: все байты заголовка суммируются отправителем и результат помещается в это поле. По получению адресат также суммирует все байты заголовка и сравнивает с этим числом. Если значения равны, значит, все в порядке. •

Urgent Point – определяет положение экстренных данных внутри сегмента. Pipe Канал – средство обмена информацией между процессами с одновременной синхронизацией, реализующей дисциплину FIFO (первый вошел – первый вышел), то есть прочитанные сообщения удаляются. Канал – файл специального типа, особенности: - время существования канала ограниченно временем работы процесса - размер канала ограничен количеством блоков, доступных для прямой адресации (то есть на диске

он не создается, а существует только в буферах ввода-вывода). - Используется только для общения между родственными процессами (поскольку родственники наследуют все открытые файлы предка). Создание Создает канал системный вызов pipe: int fd[2]; pipe(int *fd); fd[0] - дескриптор файла для ввода fd[1] - дескриптор файла для вывода Но файловый дескриптор – локальная для процесса характеристика, как могут два разных процесса использовать

один файловый дескриптор? Для этого должна возникнуть такая ситуация А это возможно только в том случае, если ПР1 и ПР2 являются родственниками – ведь потомок полностью наследует u-area предка, в том числе и таблицу файловых дескрипторов. Значит, либо ПР1 должен быть потомком ПР2, либо наоборот, либо они оба должны быть потомками третьего процесса NetBios Протокол NetBios работает на трех уровнях семиуровневой модели

OSI: сетевом уровне, транспортном уровне и на уровне каналов связи. Уровень каналов связи обеспечивает механизм обмена сообщениями между программами, работающими на станциях в рамках канала связи или сессии. NETBIOS может обеспечить интерфейс более высокого уровня, чем протоколы IPX и SPX. Протокол NETBIOS поддерживается в сетях IBM (IBM PC LAN), Novell NetWare, Microsoft Windows for

Workgroups и в других сетях. К сожалению, нет единого стандарта на протокол NETBIOS, поэтому в сетевом программном обеспечении разных фирм используются разные интерфейсы для вызова команд NETBIOS. С нашей точки зрения, наибольший интерес представляет применение NETBIOS в сетях Novell NetWare и Microsoft Windows for Workgroups. Мы рассмотрим основные возможности NETBIOS, связанные с передачей данных между рабочими

станциями в пределах одного логического сегмента сети. Использовать NETBIOS проще, чем IPX или SPX. Однако, так как в среде Novell NetWare нужен специальный эмулятор NETBIOS, эффективность работы программы может снизиться. Кроме того, для эмулятора нужна дополнительная память, так как он реализован в виде резидентной программы. Адресация станций и программ Для идентификации рабочей станции протоколы

IPX и SPX используют номер сети, адрес станции в сети и сокет. Адрес станции определяется на аппаратном уровне и представляет собой число длиной 6 байт. Номер сети занимает 4 байта. Сокеты выделяются динамически драйвером протокола IPX или могут быть получены в Novell. Протокол NETBIOS использует другой механизм адресации станций и программ. Для адресации станции используются имена размером 16 байт.

Каждая станция имеет одно постоянное имя (permanent name), которое образуется из аппаратного адреса добавлением к нему слева десяти нулевых байт. Кроме постоянного имени протокол NETBIOS позволяет добавлять (и удалять) обычные имена и групповые имена. Обычные имена служат для идентификации рабочей станции, групповые могут служить для посылки пакетов одновременно нескольким станциям в сети. Постоянное имя удалить нельзя, так как оно полностью определяется

аппаратным обеспечением станции. При добавлении обычного имени протокол NETBIOS опрашивает всю сеть для проверки уникальности имени. Групповое имя может быть одинаковое на нескольких станциях, поэтому при добавлении группового имени опрос сети не выполняется. После добавления нового имени этому имени присваивается так называемый номер имени (name number), который используется для передачи данных по сети.

Сравнивая методы адресации, используемые протоколами IPX/SPX и NETBIOS, нетрудно заметить, что метод адресации протокола NETBIOS более удобен. Вы можете адресовать данные не только одной станции (как в IPX и SPX) или всем станциям сразу (как в IPX), но и группам станций, имеющим одинаковое групповое имя. Это может быть удобно, если в сети работают несколько групп пользователей, которые интенсивно обмениваются

данными между собой. Другим преимуществом схемы адресации протокола NETBIOS перед схемой адресации протоколов IPX/SPX можно считать отсутствие необходимости получать в фирме Novell свой собственный номер сокета для идентификации вашего программного обеспечения. Вы можете придумать свое собственное уникальное групповое имя, включающее, например, название программы и вашей фирмы, и использовать его для работы по схеме клиент-сервер.

MailSlot Канал Mailslot создается серверным процессом с помощью специально предназначенной для этого функции CreateMailslot. После создания серверный процесс получает идентификатор канала Mailslot. Пользуясь этим идентификатором, сервер может читать сообщения, посылаемые в канал клиентскими процессами. Однако сервер не может выполнять над каналом Mailslot операцию записи, так как этот канал предназначен только для односторонней передачи данных -

от клиента к серверу. При ошибке функцией CreateMailslot возвращается значение INVALID_HANDLE_VALUE. Код ошибки можно определить при помощи функции GetLastError. Прежде чем приступить к работе с каналом Mailslot, клиентский процесс должен его открыть. Для выполнения этой операции следует использовать функцию CreateFile. Запись сообщений в канал Mailslot выполняет клиентский процесс, вызывая для этого функцию

WriteFile. Серверный процесс может читать сообщения из созданного им канала Mailslot при помощи функции ReadFile. Заметим, что перед выполнением операции чтения следует проверить состояние канала Mailslot. Если в нем нет сообщений, то функцию ReadFile вызывать не следует. Для проверки состояния канала вы должны воспользоваться функцией GetMailslotInfo. С помощью функции SetMailslotInfo серверный процесс может изменить время ожидания для

канала Mailslot уже после его создания.