Почему нет дополнительного канала для сообщения об ошибке или состоянии?

#database #tcp #client-server #stderr

Вопрос:

У меня есть вопрос по Клиент-Серверным вычислениям.

Почему существует только одно соединение от сервера обратно к клиенту? В UNIX у вас обычно есть stdout и stderr.

Предыстория: Запросы к базе данных могут занять гораздо больше времени, чем вы ожидали. Тогда вы задаетесь вопросом, не случилось ли что-то не так. Возможно, сервер застрял в бесконечном цикле. Это легко может быть так, потому что в настоящее время серверы могут быть расширены с помощью процедур, триггеров и т.д.

Если бы был дополнительный порт для отправки сообщений о состоянии с сервера клиенту, пользователь мог бы получить информацию «все в порядке», например, через «выполнение узла № 7 плана выполнения запроса».

Эти пользователи, которые только были бы озадачены такой информацией, могли бы держать окно сообщения закрытым.

Есть ли реальная техническая проблема или нужно, чтобы ответственные за стандартизацию TCP просто намекнули?

Ответ №1:

TCP является универсальным транспортным протоколом и не различает различные семантики, такие как состояние, ошибка, данные,… Такая семантика добавляется прикладным протоколом поверх TCP.

Чтобы обеспечить различную семантику, не обязательно иметь разные TCP — соединения. Можно легко определить протокол приложения, который позволяет передавать сообщения с различной семантикой по одному и тому же TCP-соединению. И такие протоколы существуют, например TLS (сообщения о рукопожатии, данные приложений, оповещения …). Но можно также выполнить несколько TCP-соединений, как в FTP, с различными TCP-соединениями для управления и передачи данных.

Поэтому вместо этого следует задать вопрос, почему конкретное серверное приложение не имеет возможности обновлять статус параллельно с запросами. Это определенно не из-за ограничений использования TCP в качестве транспортного уровня, а из-за ограничений в самом приложении.

Комментарии:

1. Спасибо вам за этот здравый ответ. Таким образом, это определенно возможно, и поскольку разные СУБД имеют разные TCP-порты, это не общий вопрос (о SQL), но это решение программистов каждой СУБД самостоятельно.