Эта история была написана в продолжение следующего вопроса StackOverflow: https://stackoverflow.com/questions/54608064/how-to-implement-websocket-client-reconnect-after-some-time-in-vertx/54617812#54617812
Итак, вы хотите написать свой собственный сервер websocket, и решили сделать это в Vert.x
Хорошая идея!
Начнем с создания нашего WebSocksServerVerticle:
Обычно рекомендуется заключить большую часть кода Vert.x в Вертикальные статьи. Также старайтесь не писать бизнес-логику внутри start() метода.
Вместо этого извлеките его в отдельный метод.
WebSocketServer похож на HttpServer, но с WebSockets:
Кто-то должен начать разговор. Итак, при каждом новом подключении наш сервер websocket будет отправлять сообщение «ping».
Чтобы было немного интереснее, наш сервер должен время от времени закрывать соединение. Обратите внимание, что это изящное закрытие. Мы также могли имитировать различные виды сбоев, но на данный момент закрытия будет более чем достаточно.
Когда мы закончили с сервером, перейдем к клиенту.
Еще раз разбейте код на части, не добавляйте логику в start() метод:
Наш клиент подключается к localhost:8080, как было указано на сервере.
На каждое сообщение «пинг» мы отвечаем сообщением «понг». Не очень изобретательный, но выполняет свою работу.
Интересно то, что мы указываем два обработчика: exceptionHandler будет запускаться, когда что-то выйдет из строя, резко, и closeHandler будет запускаться при изящных событиях.
Наконец, давайте посмотрим, как выглядит restart():
Как видите, не помещать все в start() метод позволяет повторно использовать логику.
Также не забудьте закрыть предыдущий клиент перед созданием нового.
Развертывание довольно простое:
Мы ждем, пока сервер запустится, прежде чем запускать нашего клиента.
Результат должен выглядеть примерно так:
Server pong Client ping Server pong Client ping Server pong Closed, restarting in 10 seconds Client ping Server pong Client ping
Выводы
Написание клиента или сервера websocket с использованием Vert.x не требует более 10 строк кода.
Решение проблем с подключением очень важно.
Вы можете обрабатывать как закрытые соединения, так и исключения, или только один из этих случаев. В реальном приложении также неплохо проверить тип полученного вами исключения (IOException или что-то еще?), А в случае изящно закрытых соединений - код ответа.
