Замедляется реконнект вебсокетов в Firefox. Почему так? Как побороть?

Question

[Дмитрий Макаров]

Здравствуйте, коллеги!

Реализую общение с сервером с помощью WebSocket`ов.
По плану должен быть автоматический реконнект.
Делаю вот таким кодом:

"use strict";

let webSocket = undefined;
let timer = 0;

function Link (url) {
	function startWebSocket () {
		if (webSocket !== undefined) return;

		webSocket = new WebSocket(url);

		webSocket.onmessage = event => console.log(event);
		webSocket.onopen = () => { 
			if (timer === 0) return;
			clearInterval(timer);
			timer = 0;
		};
		webSocket.onclose = () => {
			webSocket = undefined;
			if (timer === 0) timer = setInterval(startWebSocket, 1000);
		};
	}

	function sendMessage (message) {
		if (webSocket === undefined) return;
		webSocket.send(message);
	}

	return {
		send: sendMessage,
		start: startWebSocket
	};
}

export default Link;

Из кода все лишнее убрал. Есть еще предобработка принятых сообщений и генерация событий на открытие/закрытие/ошибку/принятое сообщение, но это к делу не относится.

Есть проблема. В Firefox`е. После порядка 10 попыток коннекта пауза между попытками увеличивается до 30 и более секунд. В Chrome такого не наблюдается.

Это бага или фича?

Как победить такое поведение?

UPD: в комментарии подробно описал: как по моему мнению работает код.

Comments

[Дмитрий Макаров]

Александр +: Тут несколько все по другому устроено. Функция Link, по сути, конструктор. Она даже через new может быть вызвана (но можно и как обычную функцию вызывать). В результате она она вернет объект, который может управлять соединением, который инкапсулирует сам WebSocket и который можно передавать в другие модули как зависимость, если есть такая необходимость.
Возвращаемый объект link один на соединение (у меня в приложении использется одно соединение, то есть вообще один объект подобного вида на приложение). Но даже если мы их настрогаем 5 штук на один хост/порт они до запуска друг с другом не будут конфликтовать, поскольку пока соединение не открыто.
Когда мы методом start откроем соединение у одного из link`ов, запуск последующих завершится исключением из-за занятости текущего хоста/порта. Но мы так делать и не будем, поскольку link в приложении предусматривается один.
Если мы несколько раз подряд вызовем метод start, то ничего не произойдёт, поскольку внутренний webSocket был создан в прошлый раз, в начале метода start на это есть проверка и метод просто завершится, не выполнив ничего.
Подразумевается, что соеднинение не может быть закрыто программно по инициативе клиента/браузера (кроме как закрытия вкладки).
Соответственно, закрытие соединения может быть только по инициативе сервера, ну или по причине неполадок со связью (провод дернули, сетевой интерфейс выключили и тпх). И то, и другое, в итоге, должно привести у webSocket`а к вызову onclose (а то и нескольких, на что предусмотрена дополнительная проверка с помощью переменной timer). На onclose навешан отложеный запуск метода start, который по новой откроет новый WebSocket.
То есть получается одновременно висящих в памяти открытых WebSocket`ов не будет по двум причинам, из-за конфликтов за хост/порт и из-за того, что новый WebSocket открывается только тогда, когда предыдущий уже закрывается.

Предположение:
Возможно как раз в этом месте проблема. Закрывающийся в firefox`е WebSocket закрывается не мгновенно и как-то может придерживает хост/порт, но поскольку состояние у него "уже закрываюсь", то новый WebSocket не генерирует исключение, а встает в очередь и дожидается пока ему хост/порт дадут. А в Chrome типа сразу хост/порт высвобождается..... Но как бы это подтвердить/опровергнуть? И что с этим делать?

[Дмитрий Макаров]

Хм....а еще вот интересно как ведут себя Firefox и Chrome если соединение невозможно установить? надо поизучать где-то, поэкспериментировать....

[Дмитрий Макаров]

Нашел вот такую замечательную штуку: https://github.com/joewalnes/reconnecting-websocket. Делает именно то, что мне нужно. Вопрос остается. Пока не изучал как реализовано...