Расширение Сокетов в JDK 1.1

спецификации, руководства, описания, API

Расширение Сокетов в JDK 1.1

Некоторые из улучшений java.net классы в JDK 1.1 позволяют сокетам (Socket/ServerSocket) быть незаключительными, растяжимыми классами. Основная цель состоит в том, чтобы позволить расширенным сокетам использоваться whereever, Сокет базового класса используется, не переписывая код программы. Таким образом, например уже существующему почтовому клиенту можно было вручить подкласс Сокета, который действительно взаимодействует с аутентификацией или шифрованием, которое подкласс Сокета обработал бы прозрачно. Другие примеры включают сокеты, которые прозрачно используют сжатие, или которые добавляют функциональность, такую как зеркальное отражение трафика к многократным серверам (например, использующий надежную упорядоченную многоадресную передачу).

У этого документа есть следующие разделы:

JDK 1.0: SocketImpl
JDK 1.1: незаключительные Классы Сокета и ServerSocket
Сокет: Как расширить Сокет
ServerSocket: Как расширить ServerSocket

JDK 1.0: SocketImpl и SocketImplFactory

JDK 1.0 позволяет лицам, имеющим патент расширять функциональность сокета одним очень определенным способом: они могут разделить на подклассы java.net.SocketImpl , и обеспечьте улучшенный java.net. SocketImplFactory (), который возвращает такие классы как необходимый.

Схема SocketImpl/SocketImplFactory полезна для, и была разработана для, приложения/приложения java, чтобы быть переносимой через среды, которые используют различные транспортные механизмы. Клиентское приложение, которое использует java.net. Сокет может работать в общем случае (где время выполнения использует PlainSocketImpl), так же как в средах, где сетевые соединения должны сделать что-то определенное. Например, программа java должна быть в состоянии работать позади брандмауэра, где соединения с Интернетом должны быть сделаны через протокол прокси, как SOCKS, предполагая, что правильный вид SocketImpl устанавливается для среды выполнения Java в той среде.

Хотя SocketImpl полезен для вещей как прозрачное оказывание поддержки прокси приложениям java, его утилита ограничивается как способ обеспечить добавленную функциональность сетевого транспорта, или для иерархического представления другие протоколы сверху TCP. Дополнительно, только возможно иметь единственный тип SocketImpl, установленного для среды выполнения Java, которая ограничивает крупномасштабные приложения. Это более чисто и более интуитивно, чтобы сделать ServerSocket и Сокет растяжимыми.

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

Изменение в JDK 1.1

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

JDK, измененный:

Удаление final модификатор от Socket и ServerSocket классы.
Повторное присоединение этого final модификатор только к методам, где необходимо избежать обходить вызовы менеджера безопасности.
Определение нового метода в ServerSocket с подписью: protected final void implAccept(Socket client) использовать, инициализируя недавно принятый сокет.
Представление значения по умолчанию Socket конструктор так, чтобы подклассы Сокета могли инициализировать свой суперкласс, не делая фактическое соединение в суперклассе. Это также требуется так, чтобы ServerSocket, из которого подклассы могут возвратить корректный подкласс Сокета, принял () (например, FooServerSocket.accept () возвращает FooSocket),

Изменения, чтобы Снабдить сокетом

Общедоступные конструкторы к Сокету общей формы:

        Socket(String host, int port) {
          ...
        }

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

        protected Socket() {
          /* install system-default SocketImpl */
          ...
        }

        protected Socket(SocketImpl impl) {
          this.impl = impl;
        }

Первый конструктор устанавливает системное значение по умолчанию SocketImpl (или от фабрики или от PlainSocketImpl). Второе позволяет для подкласса Сокета устанавливать свой собственный impl в случае необходимости. Если подкласс Сокета не нуждается в SocketImpl по умолчанию, это совершенно допустимо, чтобы использовать второго конструктора и передать это нуль. (Но в этом случае подкласс должен, конечно, переопределить все методы базового класса, так как они все полагаются на базовый SocketImpl).

Изменения к ServerSocket

Подклассам ServerSocket также представляли защищенного конструктора им, который создает SocketImpl по умолчанию в базовом классе, но иначе не инициализирует его (например, не вызывает impl.create (), impl.bind () или impl.listen ()). Общедоступные конструкторы ServerSocket инициализируют базовый SocketImpl.

        protected ServerSocket() {
          /* install system-default SocketImpl */
          ...
        }

Единственная другая вещь о расширении ServerSocket, который должен быть объяснен, состоит в том, как переопределить, принимают (), когда базовый SocketImpl для Socket/ServerSocket не является accesible к подклассам. Так как базовый класс может сделать это, у ServerSocket есть метод, чтобы сделать необходимые запросы к базовому SocketImpl от имени подклассов:

public class ServerSocket {
        ...
        protected final void implAccept(Socket s) throws IOException {
           ...
           // on return from this call s will be connected to a client
        }
        ...

Отметьте, что подклассы Socket/ServerSocket, который не использует SocketImpl, не должны использовать этот метод. Как пример того, как это работает, вот то, на что мог бы быть похожим некоторый код SSL.


class SSLServerSocket extends ServerSocket {
    ...
    public Socket accept () throws IOException
    {
        SSLSocket s = new SSLSocket (certChain, privateKey);
        // create an unconnected client SSLSocket, that we'll
        // return from accept

        implAccept (s);
        s.handshake ();
        return s;
    }
    ...
}

class SSLSocket extends java.net.Socket {
    ...
    public SSLSocket(CertChain c, PrivateKey k) {
        super();
        ...
    }
    ...
}

Свяжитесь с Нами