Текст книги "Платформа J2Me"

Автор книги: Автор Неизвестен

сообщить о нарушении

Текущая страница: 13 (всего у книги 21 страниц)

1. Оно создает объект DatagramConnection.

2. Получает объект Datagram из объекта DatagramConnection.

3. Затем оно заполняет объект Datagram данными, составляющими полезную нагрузку, которая будет послана принимающему объекту.

4. Запрашивает соединение о посылке дейтаграммы.

5. Запрашивает соединение о получении ответной дейтаграммы.

Чтобы создать дейтаграммное соединение, вам все равно нужно использовать класс Connector. Вы указываете, что желаете получить дейтаграммное соединение, поставляя строковую дейтаграмму в поле схемы URI, который вы передаете одной или трем формам метода Connector.open(). Полный синтаксис дейтаграммных адресов следующий:

address:= <протокол>://<адресат>

protocol:= «datagram»

target:= [<хост>]:<порт>

host:= Значимое DNS-имя хоста или его номер>

port:= Значимуй системный номер порта>

Указание полей хоста необязательно. Если вы пропускаете поле хоста, соединение представляет соединение сервера – реализация допускает, что объект, запрашивающий соединение, является сервером. Серверы не инициируют передачу сообщений, так что для указания места назначения имя хоста не требуется. Соединение сервера ожидает клиента для посылки ему дейтаграммы. Сервер извлекает адрес посылающего из дейтаграммы, полученной им, и использует его для ответа. Пример указания соединения сервера:

datagram:/7:513

Если поле хоста указано, соединение открывается как соединение клиента. Реализация предполагает, что запрашивающий является клиентом, который инициирует соединение, поскольку он желает послать дейтаграмму адресованному узлу. Пример соединения клиента, указывающего известный компьютер:

datagram://server.foo.com:513

Когда соединение установлено, ваше приложение может использовать его для отправки и получения дейтаграмм. Интерфейс javax.microedition.io.Datagram определяет дейтаграммы, которые являются частями сообщения, посланными и полученными протоколами передачи дейтаграмм. Объект DatagramConnection посылает и получает объекты Datagram. Обратите внимание, что методы, указанные в таблице 8.9, содержат несколько ссылок на тип Datagram.

В таблице 8.10 перечислены методы интерфейса Datagram. Обратите внимание, что они отражают только следующие понятия:

– адрес – представляет адрес посылающего или принимающего объекта;

– полезная нагрузка – дейтаграмма рассматривает данные как один непрозрачный объект без интерпретации его формы, структуры или типа.

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

В интерфейсе Datagram отсутствует информация о синтаксисе или семантике полезной нагрузки. Причина этого заключается всего лишь в том, что дейтаграммы не определяют синтаксиса или семантики данных, которые они переносят. Дейтаграммы просто рассматривают свою полезную нагрузку как последовательность байтов. Полезная нагрузка дейтаграммы определяется просто как byte [].

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

Интерфейс Datagram происходит из интерфейсов Datalnput и DataOutput в пакете java.io. Такое происхождение гарантирует наличие удобного интерфейса для чтения двоичных данных из дейтаграммы и записи в нее. На рисунке 8.4 показана иерархия происхождения интерфейса Datagram. В таблице 8.11 перечислены методы интерфейса Datalnput, а в таблице 8.12 перечислены методы интерфейса DataOutput. Эти интерфейсы идентичны интерфейсам пакета java.io J2SE.

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

Таблица 8.10. Методы интерфейса Datagram

Название метода интерфейса Datagram – Описание

String getAddress() – Выдает адрес в данной дейтаграмме

byte [] getData() – Выдает буфер, содержащий полезную нагрузку дейтаграмм

int getLength() – Выдает длину полезной нагрузки дейтаграммы

int getOffset() – Выдает смещение указателя для чтения/записи в буфере полезной нагрузки

void reset() – Восстанавливает позицию указателя для чтения/записи в буфере полезной нагрузки

void setAddress (Datagram reference) – Устанавливает, что адрес данной дейтаграммы является адресом указанной дейтаграммы

void setAddress (String addr) – Устанавливает адрес, указываемый строкой

void setData (byte[] buffer, int offset, int len) – Устанавливает полезную нагрузку данной дейтаграммы

void setLength (int len) – Устанавливает длину полезной нагрузки дейтаграммы

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

Таблица 8.11. Методы интерфейса Datalnput

Название метода Datalnput – Описание

boolean readBoolean() – Считывает только значение Boolean из входного потока

byte readByte() – Считывает один байт из входного потока

char readChar() – Считывает символ из входного потока

void readFully (byte [] b) – Считывает байты из входного потока, пока указанный массив не наполнится

void readFully(byte[] b, int off, int len) – Считывает указанное число байт в указанный буфер, начиная с указанного сдвига

int readlnt() – Считывает значение int из входного потока

long readLong() – Считывает значение long из входного потока

short readShort() – Считывает два входных байта и выдает значение short

int readUnsignedByte() – Считывает один байт, дополненный нулями, из потока

int readUnsignedShort() – Считывает два входных байта и выдает значение int

String readUTF() – Считывает в UTF-8 шифрованную строку символов

int skipBytes (int n) – Просматривает n байтов из входного потока

Таблица 8.12. Методы интерфейса DataOutput

Название метода DataOutput – Описание

void writeByte (byte [] b) – Записывает все байты в выходной поток

void write (byte[] b, int off, int len) – Записывает указанное число байтов в выходной поток, начиная от смещения

void write (int b) – Записывает младший байт в выходной поток

void writeBoolean (boolean v) – Записывает значение boolean

void writeByte (int v) – Записывает младший байт int

void writeChar (int c) – Записывает два младших байта в выходной поток

void writeChars (String s) – Записывает каждый символ в уникоде в выходной поток

void writelnt(int v) – Записывает int (четыре байта) в выходной поток

void writeLong (long v) – Записывает значение long (четыре байта) в выходной поток

void writeShort (int v) – Записывает int как два байта в выходной поток

void writeUTF(String s) – Записывает каждый символ в формате Java LJTF, которому предшествуют два байта, показывающие длину в байтах

Например, если приложение MIDP хочет взаимодействовать со стандартным демоном синхронизирующего сетевого протокола Unix (Unix Network Time Protocol (NTP)), оно должно создать соединение, которое использует стандартный номер порта демона NTP, то есть 123. Приложение-клиент MIDP должно задать формат полезной нагрузки ответных дейтаграмм, придерживаясь определения NTP. Оно также должно быть способно анализировать ответ, возвращенный сервером.

MIDP кое в чем отличается от платформы J2SE в своей поддержке дейтаграммных соединений. J2SE имеет пакет java.net. Например, ее класс, DatagramPacket определяет дейтаграмму. Класс DatagramSocket реализует протокол передачи дейтаграмм с помощью соединений сокета.

Эти классы не существуют в CLDC/MIDP. В действительности пакет java.net недоступен в CLDC/MIDP. С другой стороны, CDC содержит пакет java.net, который содержит эти классы.

В листинге 8.5 демонстрируются вышеописанные понятия. Код, описанный в этом листинге, является дейтаграммным клиентом, который соединяется с определенной дейтаграммной службой. Важными шагами, выполняемыми программой, являются следующие:

Она получает новый объект DatagramConnection. Получает объект Datagram из DatagramConnection. Заполняет Datagram должным образом отформатированной семантической информацией, которая составляет запрос (как разработчик, удостоверьтесь, что длина дейтаграммы не превышает максимальной длины, позволенной протоколом). Получает ответную Datagram от DatagramConnection. Этот вызов блокирует обработку до тех пор, пока дейтаграмма не будет получена или время вызова не истечет. Обрабатывает данные в дейтаграмме. Повторяет цикл для следующих взаимодействий.

Программа, описанная в листинге 8.5, на самом деле не осуществляет этап 3. Его выполнение требует создания должным образом отформатированного сообщения, как ожидается службой, с которой соединяется клиент. Также «обработка», указанная в шаге 5, включает лишь вывод ответа сервера в стандартный результат. В настоящих приложениях клиент использовал бы дейтаграммную информацию для локальной обработки.

Листинг 8.5. Дейтаграммы посылаются и получаются дейтаграммным соединением. Эта программа анализирует полезную нагрузку полученной дейтаграммы и отображает ее на экране

import javax.microedition.midlet.MIDlet;

import javax.microedition.Icdui.Display;

import javax.microedition.Icdui.Command;

import javax.microedition.Icdui.CommandListenerj;

import javax.microedition.Icdui.Displayable;

import javax.microedition.Icdui.TextBox;

import javax.microedition.Icdui.TextFie Id;

import javax.microedition.io.Connector;

import javax.microedition.io.Datagram;

import javax.microedition.io.DatagramConnection;

import Java.io.lOException; ft,

Этот класс реализует дейтаграммкого клиента, который соединяется с сервером синхронизирующего сетевого протокола (NTP) через стандартный порт NTP 123.

Для контроля клиента назначается отдельная нить, поэтому он реализует Runnable. Приложение может осуществлять коммуникации асинхронно из управления его пользовательским интерфейсом.

Обратите внимание, что данный файл представляет только «скелет клиента».

Полная семантика сообщений службы NTP здесь не показана. Цель в том, чтобы просто продемонстрировать структуру клиента с помощью дейтаграмм MIDP.

*/

public class DatagramTest extends MIDlet,

implements CommandListener, Runnable

}

private static final int BUF_SIZE = 1024;

private static Command exit =

new Command ("Exit", Command.EXIT, 1);

private static DatagramTest instance; private Display display;

private TextBox dgramText;

// Дейтаграммное соединение. private DatagramConnection conn;

// Дейтаграмма, которая поддерживает посылку

и получение данных, private Datagram dgram;

// Адрес демона синхронизирующего сетевого протокола (NTP) на

// определенном сервере. NTP использует протокол UDP. private String address = "datagram://srl-usca28-07:123";

/"*

Конструктор No-arg.

*/

public DatagramTest()

{

super (); instance = this;

}

/**

Конструктор.

Обратите внимание, что проверок действительности параметра не осуществляется. Если он деформирован, при попытке соединения будет сброшено исключение.

@param service URI дейтаграммной службы, с которой соединяемся.

*/

public DatagramTest(String service)

(

this ();

address = service;

}

/**

Выдает один экземпляр данного класса. Вызов данного метода до создания объекта возвращает нулевой указатель.

@выдает экземпляр данного класса.

*/

public static DatagramTest getlnstance()

}

return instance;

{

public void startApp()

}

display = Display.getDisplay (this);

dgramText = new TextBox("Datagram contents", null, 2048,

TextField.ANY); dgramText.setCommandListener (this);

display.setCurrent(dgramText); run ();

}

/*

Запускает дейтаграммного клиента.

Открывает соединение со службой дейтаграммы.

Заполняет объект дейтаграммы и посылает его. Получает ответ асинхронно и записывает байты в стандартный результат для демонстрации. Бесшумно перехватывает исключения, связанные с любым соединением.

*/

public void run ()

}

try int maxLength;

// Откройте клиентское соединение,

conn = (DatagramConnection) Connector.open(address);

maxLength = conn.getMaximumLength();

dgram = conn.newDatagram(maxLength);

// Убедитесь, что указатель для чтения/записи находится в

// начале буфера, так что данные будут переписывать

// буферную память, dgram.reset();

// Заполните дейтаграмму перед посылкой сообщением,

// которое служба дейтаграммы поймет.

// Создайте запрос в дейтаграмме.

**/

// Пошлите только что заполненную дейтаграмму. conn.send(dgram);

// Получите дейтаграмму; ее содержимое помещается в

// указанный объект дейтаграммы. conn.receive(dgram);

// Используйте данный байтовый массив для пересылки содержимого

// ответа сервера более управляемому объекту Java,

// как, например, String. Вы можете затем использовать

// дейтаграмму для другого события пересылки или получения.

byte [] data = dgram.getData ();

// Извлеките строку ответа. String str = new String (data);

// Проделайте обработку ответа. Здесь он

// просто распечатывается для демонстрации. System.out.println(str);

// Переустановите указатель для чтения/записи для объекта

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

// в буфер дейтаграммы, он перепишет данные последней операции

// по пересылке или получению.

//Это гарантирует, что предыдущие и последующие данные не

// перемешаются в одном буфере и что не будет создано

// испорченных засоренных сообщений.

dgram.reset();

// Продолжайте обработку, возможно, посылая и получая другие

// сообщения сервера.

//….

}

catch (lOException ioe)

(

System.out.println(ioe.getMessage());

loe.printStackTrace();

quit();

}

return;

}

public void pauseApp()

{

}

void quit()

destroyApp(true); notifyDestroyed(); }

public void destroyApp(boolean destroy) }

try }

conn.close ();

}

catch (lOException ioe) ioe.printStackTrace();

public void display!)

Display.getDisplay(this). setCurrent(dgramText);)

public void commandAction(Command c, Displayable d)

{

if (c == exit)

}

quit();

}

}

}

Обратите внимание, что любой из объектов Datagram по умолчанию содержит тот же адрес, что и создающий их объект DatagramConnection. Вы можете изменять адрес дейтаграммы с помощью методов интерфейса Datagram.

Приложение должно поставлять объект Datagram для посылки или получения дейтаграммы. Чтобы послать дейтаграмму, приложение заполняет объект дейтаграммы данными, составляющими сообщение, которое должно быть послано на сервер. Когда приложение получает дейтаграмму, его объект соединения заполняет объект дейтаграммы данными, которые оно получает от посылающего устройства.

Вы можете использовать тот же объект дейтаграммы для посылки и получения нескольких сообщений. Чтобы сделать это, вы должны убедиться, что вы не перепутали данные нескольких сообщений. Перед повторным использованием объекта дейтаграммы для посылки или приема нового сообщения используйте метод Datagram.reset() для переустановки указателя чтения/записи буфера.

Объект Datagram имеет буфер, в котором хранятся байты, составляющие сообщение, которое будет послано или получено. Если вы повторно используете объект Datagram, байты, которые были помещены в буфер предыдущей операцией посылки или получения, все еще будут находиться там. Вызов reset () устанавливает сдвиг указателя чтения/записи на начало данного буфера и устанавливает длину на 0. Таким образом, вы эффективно переписываете данные любой предыдущей операции, гарантируя, что вы не смешаете байты двух отдельных сообщений.

Соединения coкeтa

Соединения сокета являются последним типом соединений, явно представленных сетевой инфраструктурой MIDP. Реализации MIDP, поддерживающие сокеты, реализуют традиционные сокеты стиля UNIX. Стоит напомнить еще раз, что от реализаций не требуется поддерживать какой-либо механизм соединения, кроме HTTP 1.1. Многие из них не хотят поддерживать соединения сокета.

Интерфейс StreamConnectionNotifier представляет известный сокет сервера. Интерфейс StreamConnection, который вы видели ранее, представляет сокет клиента.

Сокет – это сетевой механизм транспортного уровня, который обычно реализует пару протоколов TCP/IP в фиксированных межсетевых средах. Сокет сервера является программой, предоставляющей сетевую службу для соединений через сокеты.

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

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

Однако сокеты не всегда реализуются с помощью TCP/IP. Тем не менее, поскольку TCP/IP является стандартной парой протоколов Интернета транспортного и сетевого уровня, системы, которые реализуют сокеты с помощью других механизмов, должны связываться с Интернет-узлами с помощью шлюза. Это требование действует как в среде фиксированных сетей, так и в беспроводном Интернете.

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

Протоколы уровня приложений могут быть определены поверх протоколов транспортного уровня, если это необходимо. Реализация протокола уровня приложений использует любой доступный механизм транспортировки. Например, HTTP является протоколом уровня приложений. Создатели приложения MIDP могут выбирать, не создать ли протокол уровня приложений непосредственно поверх механизма сокета, если таковой поддерживается. Если сокеты не поддерживаются, сообщения протокола уровня приложений могут быть туннелированы с помощью HTTP. Протокол уровня приложений ответственен за определение своего собственного состояния, которое отличается от состояния протокола транспортного уровня.

Модель соединения сокета. Соединения сокета устанавливаются также, как и другие типы соединений, клиенты используют метод Connector.open() и указывают URI базирующейся на сокетах службы, с которой они хотят соединиться. Однако со стороны сервера модель соединения немного отличается из-за определяемой соединениями природы сокетов. Эта модель необходима для серверов, чтобы иметь возможность обеспечивать многочисленные одновременные соединения клиентов.

Это стандартная идиома, которую вы должны использовать для того, чтобы работать с сокетами сервера. Она та же, что и модель соединения сокета стиля Unix. Следующие этапы описывают сценарий соединения:

1. Демон сервера устанавливает соединение, которое связано с известным сокетом – сокетом сервера, чей порт и служба были предварительно установлены и объявлены.

2. Демон сервера прослушивает запросы соединения клиента.

3. Клиент создает запрос соединения для демона сервера и ожидает отклика.

4. Демон принимает запрос соединения и создает новое соединение с клиентом, сервер связывает соединение с новым сокетом. Сервер создает новый объект приложения, который будет взаимодействовать с клиентом через новое соединение и порождает нить для контролирования этого объекта.

5. Запрос соединения клиента возвращается. Приложение клиента теперь имеет объект соединения, чьей конечной точкой является новый сокет, созданный сервером.

6. Клиент и сервер взаимодействуют через новое соединение.

7. Демон сервера продолжает прослушивать последующие запросы соединения на известном сокете.

На рисунке 8.5 показано схематичное представление этого процесса. Порядок этапов в вышеописанном списке соответствует порядку, показанному на рисунке 8.5.

Рисунок 8.5. Базирующиеся на сокетах службы должны быть способны выполнять асинхронную обработку. Демон порождает нить для контролирования взаимодействия с каждым клиентом

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

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

Идиома открытия сокетов очень сходна с идиомой открытия дейтаграмм. Приложения пересылают URI в метод создания Connector.open() для получения соединения. Синтаксис LJRI следующий:

address:= <протокол>://<адресат>

protocol:= «socket»

target:= [<хост>]:<порт>

host:= Оначимое DNS-имя хоста или его номер>

port:= оначимый системный номер порта>

Еще раз повторюсь, присутствие или отсутствие имени компьютера в URI говорит о том, является ли соединение серверным или клиентским. Демон сервера сначала открывает соединение на своем известном сокете, как показано в следующем примере:

StreamConnectionNotifier wellKnown =

Connector.open("socket://:98765");

Спецификация MIDP также позволяет использовать схему serversocket для серверных соединений. Эта последняя схема может быть выгодна, поскольку явное использование serversocket в части кода делает более очевидным для кого-либо, читающего код, то, что серверное соединение установлено. Следующая строка кода демонстрирует использование схемы serversocket:

StreamConnectionNotifier wellKnown =

Connector.open("serversocket://:98765");

Класс StreamConnectionNotifier является MIDP эквивалентом класса Java.net.Serversocket платформы J2SE. StreamConnectionNotifier является на самом деле сокетом сервера.

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

StreamConnection clientConn = vellKnovn.acceptAndOpen();

Этот оператор блокирует операции до тех пор, пока не появится запрос клиента на соединение. При появлении запроса клиента на соединение метод acceptAndOpen () обрабатывает запрос перед передачей управления. Чтобы обработать запрос на соединение, он

1. Принимает запрос на соединение;

2. Создает новый объект соединения;

3. Связывает соединение с неиспользуемым сокетом;

4. Уведомляет клиента о новом соединении сокета.

Эти этапы объясняют название StreamConnectionNotifier. Демон сервера будет «уведомлен» о запросе на соединение при возвращении вызова блокирующего acceptAndOpen (). И он уведомляет клиента о том, что он должен прослушивать новый сокет, установленный для взаимодействия клиент-сервер. В таблице 8.13 показан единственный метод интерфейса StreamConnectionNotifier.

Таблица 8.13. Методы интерфейса StreamConnectionNotifier

Метод StreamConnectionNotifier – Описание

StreamConnection acceptAndOpen() – Возвращает новый потоковый обьект, связанный с новым сокетом и соединенный с запрашивающим клиентом

Клиенты запрашивают соединение у известного сокета, создавая клиентский запрос соединения в стандартной форме. Например, следующий оператор представляет клиентский запрос соединения:

StreamConnection conn =

Connector.open("socket://server.foo.com:98765");

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

StreamConnection conn =

Connector.open("socket://localhost:98765");

Оба вызова StreamConnectionNotifier.acceptAndOpen(} сервера и Connector.open() клиента создают объект StreamConnection. Вы уже видели класс StreamConnection при нашем обсуждении коммуникационных портов.

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

Нигде не оговаривается, какие виды протоколов может представлять интерфейс StreamConnection. Интерфейс извлекает подробную информацию о реализации протокола из приложения. Приложения не осведомлены о платформно-определяемых классах, которые реализуют интерфейсы. Хотя реализации интерфейса структуры общих соединений могут варьироваться, они должны поддерживать указанное поведение и семантику интерфейса.

Важно заметить, что не все реализации поддерживают серверные сокеты. И, из тех, что делают это, некоторые в настоящее время работают не совсем правильно. Если поддержка серверных сокетов недоступна на вашей реализации, но вы по некоторой причине должны использовать сокеты, вам придется разработать схему, по которой клиент сможет соединяться с «сервером». Сервер не сможет поддерживать модель известного сокета, ему придется определить другую модель, которая позволит клиентам получить средство установления соединения.

В листингах 8.6–8.8 демонстрируется набор классов, которые составляют структуру сокетных коммуникаций в MIDP. Смысл заключается в том, что эти классы будут использоваться приложением, которое нуждается в сокетных коммуникациях. Эти примеры составляют не больше чем основу, которая формирует базовую структуру поддержки сокетных взаимодействий. Они не являются функционирующими приложениями.

Некоторые данные были проигнорированы в этом коде. Например, сама сетевая служба не определена, нет определения синтаксиса или семантики сообщения протокола уровня приложений. Кроме того, код не обращается к очистке рабочих нитей со стороны сервера. Следующие классы являются классами, составляющими данный пример:

– ServerSocket – определяет демон сервера, который прослушивает известный сокет на предмет клиентских запросов соединения.

– Server Agent – определяет объект, один экземпляр которого демон создает для каждого клиентского запроса. Каждый экземпляр взаимодействует с клиентом. Данный класс определяет действительную службу.

– ClientSocket – представляет клиента.

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

import javax.microedition.io.Connector;

import javax.microedition.io.StreamConnection;

import javax.microedition.io.StreamConnectionNotifier;

import Java.io.lOException;

/**

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

Он открывает соединение на предварительно определенном номере порта.

А затем блокирует обработку на данном порте, ожидая клиентского запроса соединения.

Когда запрос появляется, он принимает его и открывает новое соединение сокета. Эти два этапа выражаются в реализации, уведомляющей реализацию клиента о новом соединении сокета.

Этот сервер затем порождает компонент и передает его новому объекту соединения. Компонент запускает отдельную нить. Компонент теперь свободен для взаимодействия с клиентом асинхронно от продолжающейся работы сервера.

public class ServerSocket imlements Runnable

{

// Порт по умолчанию, на котором установлен известный

// сокет. public static final String DEFAULT_PORT = «9876»;

// Порт, на котором установлен известный

// сокет. protected String wellKnownPort;

// URI, который данный сервер использует для открытия своего

// известного сокета. protected String uri;

// Соединение с известным сокетом.

protected StreamConnectionNotifier wellKnownConn;

// Соединение сокета, которое соединяется с клиентом,

protected StreamConnection clientConn;

/**

Конструктор для подклассов.

*/

protected ServerSocket()

super ();

/**

Конструктор.

@param port Известный порт, на котором устанавливается этот объект как блок прослушивания.

*/

public ServerSocket (String port)

}

thisl); if (port == null)

{

wellKnownPort = DEFAULT_PORT;

}

else

}

wellKnownPort = port;

}

setURI(port);

{

protected void setURI(String port)

{

StringBuffer buf = new StringBuffer("socket://:");

buf.append(port); uri = buf.toString();

}

/**

Запустите данный сервер. Этот метод должен бытьвызван явно после создания данного объекта. Он запускает прослушивание запросов клиентов на известном сокете.

Оператор вызова должен запустить это выполнение в отдельной нити.

*/

public void run()

{

while (true)

{

try

{

// Откройте соединение известного сокета для данной

// «службы». wellKnownConn = (StreamConnectionNotifier)

Connector.open(uri);

//Прослушиваем запросы соединения. Данный вызов

// блокирует работу до тех пор, пока не будет получен

// запрос на соединение.

clientConn = wellKnownConn.acceptAndOpen()

// Создадим экземпляр агента» сервера, объект, который

// представляет службу для клиента. Каждый экземпляр

// взаимодействует с одним клиентом.

// Порождаем нить для взаимодействия с

// клиентом, создавшим запрос на соединение.

ServerAgent agent = new ServerAgent(clientConn);

Thread thread = new Thread (agent);

} catch (lOException ioe)

(System.out.printlnfioe.getMessage!));

ioe.printStackTrace(); break;

)

}

}

}

Листинг 8.7. Агент сервера является объектом, который взаимодействует с клиентом независимо от демона сервера. Он запускает свою собственную нить, позволяя другим экземплярам одновременно взаимодействовать со своими клиентами