Автор неизвестен - Платформа J2Me

}

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. Таким образом, вы эффективно переписываете данные любой предыдущей операции, гарантируя, что вы не смешаете байты двух отдельных сообщений.

Соединения сокета являются последним типом соединений, явно представленных сетевой инфраструктурой 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");