Затем я приступил к реализации его в игре, и хотел проверить свою систему массового обслуживания, поэтому я выключил подключение к интернету и повернул его обратно - и с удивлением обнаружили, что связь выжила это, и пропущенное сообщения были отправлены через одно и то же соединение. Не нужно повторно подключать и отправлять отставание в новое соединение.
Отключение соединения не приводит к автоматическому отключению любых сокетов, установленных по этому соединению. сокеты в конечном итоге закрываются, когда они безуспешно пытаются отправить данные, и после нескольких попыток и прохождения времени все, что они получают, это ошибки. Если сокет не пытается активно отправлять какие-либо данные и не имеет какой-либо конфигурации, которая может сделать это автоматически, тогда он может сидеть там часами с мертвым соединением и просто не знать, что соединение мертво. Пока сокет не используется, нет автоматического способа, чтобы он даже знал, что это сквозное соединение больше не функционирует. Только тогда, когда он пытается использовать соединение и получает сообщение об ошибке, это будет понятно.
Обратите внимание, что все было бы иначе, если бы серверный процесс разбился, но соединение оставалось живым. В этом случае стек TCP на сервере увидит, что серверный процесс выйдет из строя и попытается очистить все сокеты, которые он использует, и отправит тесные пакеты на другой конец, а другой конец будет проактивно сказать, что сокет был закрыто. Но ваш случай просто нарушить транспорт не делает то же самое.
Похоже, что технология websocket уже обрабатывает автономную очередность? Имеет ли смысл даже усложнять код сервера, делая это сам (и добавляя к загрузке памяти сервера, сохраняя там сообщения)?
Веб-сайт представляет собой слой протокола поверх сокета TCP. TCP предназначен для надежного транспорта, что означает, что когда у него возникают проблемы с отправкой данных (но он не получил никакого уведомления о том, что сокет был закрыт другим концом), он зависает с этими данными и повторяет попытку. В конце концов он откажется и вернет некоторую ошибку.
Возможно, вас заинтересует socket.io, который является слоем поверх webSocket.Он добавляет пару вещей, которые здесь актуальны:
- Обычный пинг от конца до конца, чтобы он знал, когда транспорт был прерван.
- Бесшовные автоподключения при закрытии гнезда или транспортировке прерваны.
- Автоматическая очередность передачи данных, когда соединение временно прерывается.
Кроме того, как он может поддерживать соединение сокета без подключения к Интернету? Существует ли стандартизованный тайм-аут для него, или обе стороны будут отслеживать его, если я не закрою его вручную?
Как я уже говорил ранее, если ни один конец пытается отправить данные и подключение к Интернету прерывается где-то посередине между двумя конечными точками, то WebSocket может просто не знать, что связь в настоящее время не функционирует. Единственный способ регулярно знать, является ли соединение функциональным, - это отправлять данные по всему соединению и видеть, получаете ли вы своевременный ответ. Это то, что socket.io делает со своими сообщениями ping/pong.
Способ сохранения логического соединения, независимо от того, что происходит с физическим подключением, - использовать дополнительный слой поверх физического соединения (например, socket.io делает поверх webSocket). Это позволяет вам иметь код, который может перезапустить физическое соединение без изменения логического соединения. Это именно то, что socket.io делает с клиентской стороны. Если вам нужно что-то похожее на стороне сервера, вам, вероятно, потребуется реализовать собственную очередь данных, которую вы хотите отправить клиенту, и только удалять вещи из очереди, когда вы уверены, что они были успешно отправлены.
Как я понимаю, вы используете socket.io правильно? –
Нет, я решил использовать websockets напрямую (т. Е. Требует ('websocket'). Server), потому что мне не нужны резервные копии ajax, которые есть у socket.io. – SvenM
Я прочитал и сделаю записку полгода назад ** Гарантированное подтверждение доставки сообщения оказалось невозможным, но TCP гарантирует доставку и заказ с учетом «бесконечных» попыток. ** Вы можете попробовать Wireshark или аналогичные инструменты для отслеживания сокетов и проведения некоторых тестов чтобы понять, как теперь работает очередь для WebSockets. –