Есть ли сетевые протоколы которые не stateless и не stateful, а управляют своим состоянием так, как я описываю ниже? Текст может содержать заблуждения и это моё мнение.
Допустим есть ftp. Старый такой протокол, его относят к семейству имеющих состояние и сервер ftp различает своих пользователей. Его ответ может зависеть от того, кому именно он отвечает и если я не ошибаюсь, там есть такие переменные как текущая директория, режим передачи файлов и т.п, одна и та же команда "дай файл" для разных пользователей может означать "дай файл в текстовом режиме" и "дай файл в бинарном режиме". Если же там действительно существует состояние текущей директории, то мы должны учитывать также и её: "дай файл в текстовом/бинарном режиме относительно следующей директории". Это может быть не пределом и работать не так. Чтобы отличать одного пользователя от другого обычно создаются сессии, так что сервер должен хранить информацию о них. По последнему запросу к серверу труднее предсказать точный ответ, потому что он зависит от "состояния", которое не содержится в запросе.
Протоколы которые мы считаем stateless работают иначе. Сервер без состояния может не различать своих пользователей и забывать о них после ответа. Http считают именно таким. Печеньки (куки) нужны для того, чтобы писать на них информацию, которую нужно где-то помнить. Не то чтобы правильно сказать, что веб-сервер слепой и различает своих пользователей по печенькам, которые он ест вместе с пользователями?
Считается, что безсостоятельные протоколы более масштабируемые, потому что например позволяют построить сеть по принципу "вас много и нас много", где можно посадить много одинаковых серверов, они будут все как один отвечать примерно одно и то же и не придётся хранить сессию... Вы можете особенно не задуматься над тем, что будет, если сессия внезапно разорвётся. Пользователь ведь сам может хранить своё состояние. Если оно у него конечно есть.
Я бы определил состояние, как всю память сервера вообще, что наверное немножко отличается от "состояния", о котором я писал выше. Ответ = запрос + состояние. Частный случай состояния - все эти переменные и сессии, но сами данные на сервере тоже несколько похожи. У команд и данных могут быть зависимости-модификаторы, например команда отправки файла зависит от запроса, состояния режима передачи файлов, состояния текущей директории и состояния файловой системы. Разные команды могут иметь разные зависимости и например не требовать всего состояния. Зная запрос и его зависимости можно предсказать ответ. Избавляемся от побочных эффектов в этой функции...
Замена команд это, относительно мощный механизм, но он всё ещё наверное не очень ложится на реальную практику использования состояний людьми. Думаю, что состояния чаще используют для того чтобы:
1 Подстроить команды под пользователя. (Разное поведение команд в зависимости от состояния).
2 Подстроить данные под пользователя. (Разные данные в зависимости от состояния)
3 Сократить передачу данных. Даже шарить всё это между ними.
4 Зависимости действий. Согласованность.
И на самом деле эти вещи близки и могут даже выражаться одним и тем же.
1 Есть ли протоколы, которые имеют это "состояние" в виде своей абстракции? Например "переменные сессии", которые могут храниться и на клиенте и на сервере. И используются переменные сессии, а мы абстрагировались от того, stateless у нас или stateful. Хотя я сейчас упростил эти понятия.
2 Логика обмена состояниями иногда кажется лишней деталью, но можно сделать протокол, который занимается только шарингом сущности типа состояния с учётом их зависимостей и больше ничем. И это уже позволит ему передавать данные, ведь даже файлы в файловой системе например похожи на состояния. Довольно удобная штука может получиться.
Зачем нам состояния? Ну тот же веб это часто stateful поверх stateless, мы можем лучше оптимизировать и кешировать, у нас они всё равно в части мест так или иначе уже есть, так что можно более стройно управлять ими.