/talk-chat-tmn

talk-chat-tmn created by GitHub Classroom

Primary LanguageKotlin

Talk

В рамках задания необходимо реализовать систему простых чатов.

Система включает

  • сервис реестра пользователей (HTTP REST API)
  • клиентские приложения работающие по разным протоколам (HTTP, WEBSOCKET, UDP)

Сервер для регистрации (подпроект registry)

Реализовать с использованием Ktor

Сервис должен поддерживать следующий интерфейс:

  • Регистрация пользователя

    POST /v1/users
    { "user" : "<name>", "address" : { "protocol" : "<HTTP | WEBSOCKET | UDP>", "host": "<host or ip>", "port": "<port>" } }
    

    В случае успеха ответ 200 OK

    { "status" : "ok" } 
    

    Если пользователь уже есть - 409 Conflict Имя пользователя не должно быть пустым, должно состоять из [a-zA-Z0-9-_.]. В случае неверного имени - 400 Bad Request

  • Обновление пользователя

    PUT /v1/users/{user}
    { "protocol" : "<HTTP | WEBSOCKET | UDP>", "host": "<host or ip>", "port": "<port>" }
    

    В случае успеха ответ 200 OK

    { "status" : "ok" }     
    

    Если пользователя нет - создать как при регистрации Имя пользователя не должно быть пустым, должно состоять из [a-zA-Z0-9-_.]. В случае неверного имени - 400 Bad Request

  • Получение списка пользователей

    GET /v1/users/
    

    В случае успеха ответ 200 OK. Пример:

    {
      "ws1" : {
        "protocol" : "WEBSOCKET",
        "host" : "127.0.0.1",
        "port" : 8083
      },
      "udp2" : {
        "protocol" : "UDP",
        "host" : "127.0.0.1",
        "port" : 3002
      },
      "http1" : {
        "protocol" : "HTTP",
        "host" : "127.0.0.1",
        "port" : 8080
      } 
    
  • Удаление пользователя

    DELETE /v1/users/{user}
    

    В случае успеха ответ 200 OK

    { "status" : "ok" }     
    

    Если пользователя нет отвечать как при успешном удалении

См. Ktor REST API

Тесты

Необходимо реализовать тесты для всех методов REST API

Дополнительное задание

Реализовать периодическую (раз в 2-3 минуты) проверку клиентов со стороны реестра.

  • Для HTTP клиентов проверять с помощью запроса к /v1/health

  • Для WEBSOCKET клиентов пробовать устанавливать соединение по основному порту.

  • Для UDP клиентов отправлять специальное сообщение со случайным идентификатором и адресом для обратного UDP запроса. В ответ на такой запрос клиент должен выполнить UDP запрос к полученному адресу и содержащий полученный случайных идентификатор.

Клиентское приложение (подпроект client)

Приложение реализует command line чат со следующими командами:

  • :update - Обновление списка пользователей, вывод пользователей и их адресов. Сообщение об ошибке, если реестр недоступен. Если выбранный пользователь был удалён - сбросить пользователя для отправки сообщений.
  • :user <user> - Выбор пользователя для отправки сообщений. Сообщение об ошибке если пользователя нет или его протокол пока не поддерживается.
  • <text> - Отправка сообщения выбранному пользователю. Сообщение об ошибке если пользователь не выбран. Сообщение об ошибке, если отправка сообщения не удалась.
  • :exit - Выход. Перед выходом удаляем клиента из реестра.

Клиент принимает сообщение по одному из трёх протоколов:

  • HTTP - порт по умолчанию - 8080, путь - /v1/message (см. Ktor REST API)
  • WEBSOCKET - порт по умолчанию - 8082, путь - /v1/ws/message (см. Ktor WebSockets)
  • UDP - порт по умолчанию - 3000 (см. Ktor Raw Sockets)

Сообщение передаётся в виде json: { "user" : "<имя отправителя>", "text": "<текст сообщение>" } При старте клиента доступны следующие опции:

  • --name - имя клиента
  • --registry - базовый URL реестра, например http://127.0.01:8088
  • --host - hostname или ip, на котором клиент будет принимать сообщения
  • --port - порт (Int), на котором клиент будет принимать сообщения
  • --protocol - протокол (HTTP, WEBSOCKET, UDP), используемый клиентом

При старте клиент регистрируется в реестре и выполняет команду :update.

Тесты

Необходимо реализовать тесты приёма сообщений для всех протоколов. Для этого можно установить свой ChatMessageListener, отправить сообщение с помощью соответствующего ChatClient и убедиться, что оно доставлено.

Дополнительное задание

Реализовать периодический (раз в 2-3 минуты) опрос реестра.