Ворошилов Алексей /70203 lab1ab

[alekseivoroshilov]

Лабораторная работа №1 (a & b)

Kotlin (версия Kotlin 1.4.30, Java 15.0.2).
Gradle (версия 6.8.3) (>6.3 required)

Описание

TCP-чат. Для отключения от сеанса клиент вводит "quit".
IP и порт назначаются в текстовом документе в той же папке: address.txt:
Ex:
127.0.0.1:8080

Тип сокетов	Сервер	Клиент
блокирующие	bserver	bclient
неблокирующие	nbserver	nbclient

Инструкция по использованию

gradle all
java -jar {выбранный сеанс}.jar

Описание используемого протокола.

Блокирующий сокет:

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

В нашем случае разницу сложно ощутить из-за отстутствия широты эксперимента, но видно, что... :

        private val output = ObjectOutputStream( socket.getOutputStream() )
        private val input = ObjectInputStream( socket.getInputStream() )

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

В любом случае, на практике чаще при больших потребностях используются неблокирующие сокеты.

Неблокирующий сокет:

Cлушающий процесс не должен делать каких-либо блокирующих вызовов и быстро реагировать на входящие сообщения, не вызывая таймауты: SocketChannelUtils.kt для создания потока сообщений по SocketChannel, где главным наличием является буферизированное чтение и запись сообщений.
Но самое важное - наличие Key - это говорит о том, что у сокета появляются разные состояния, влияющие на допуск к операциям с ним.