Сетевая рабочая группа
Категория: Экспериментальный
Дата: 01.04.2026
Автор: Георгий Тудоси | https://george.tudosi.ru

¯\_(ツ)_/¯
¯\_(ツ)_/¯

1. Введение

Целью настоящего документа является описание протокола SOS (Sex Over SMS) — надёжного механизма установления, поддержания и завершения сеанса интимного общения текстового характера через инфраструктуру коротких текстовых сообщений (SMS).

С момента появления SMS человечество столкнулось с необходимостью формализовать процессы, которые ранее регулировались исключительно культурными нормами и личным опытом: инициирование контакта, синхронизация состояний, подтверждение получения, корректное завершение диалога. Существующие стандарты (3GPP TS 23.040, RFC 5724) описывают лишь транспортировку сообщений, но не семантику обмена.

В условиях, когда доступ к некоторым мессенджерам может быть ограничен по техническим причинам, SMS остаётся общедоступным каналом связи, не требующим доступа к сети Интернет. Протокол SOS восполняет пробел в стандартизации, предоставляя единый язык для описания процессов, которые ранее приходилось объяснять «на пальцах».

2. Терминология

В настоящем документе используются следующие термины:

  • SOS-сообщение — текстовое SMS, структурированное в соответствии с разделом 3.

  • Инициатор — сторона, отправляющая первое SOS-сообщение с целью установления сеанса.

  • Целевой абонент — сторона, получающая приглашение и принимающая решение о его принятии или отклонении.

  • Состояние — этап протокольного автомата, определяющий допустимые действия стороны (см. раздел 5).

  • Служебная последовательность — комбинация символов, используемая для передачи управляющей информации или эмоционального маркера (см. раздел 4).

  • Полезная нагрузка — текст, передаваемый в рамках сеанса, который может содержать как произвольные сообщения, так и служебные последовательности.

  • Контрольная сумма — значение, вычисляемое по алгоритму, описанному в разделе 3.2, и используемое для проверки целостности сообщения.

  • Идентификатор сеанса (session-id) — целое число, присваиваемое инициатором каждому новому сеансу. Инициатор ведёт монотонно возрастающий счётчик, увеличивая его на 1 для каждого нового сеанса независимо от партнёра.

3. Формат SOS-сообщения

Каждое SOS-сообщение имеет следующую структуру (в синтаксисе, близком к ABNF):

SOS-message = start-tag "|" version "|" state "|" session-id "|" flags "|" payload-length "|" payload ["|" checksum]

start-tag = "SOS"

version = 1DIGIT ; в данной спецификации "1"

state = "IDLE" / "SYNS" / "SYNR" / "ESTD" / "FINW" / "PRMT" / "BUSY" / "SUSP" / "CLSD" / "MORE"

session-id = 5DIGIT; от 1 до 65535

flags = flag-charflag-char = "A" / "F" / "R" ; ACK, FIN, RST

payload-length = 3DIGIT ; длина полезной нагрузки в символах (0–160 с учётом заголовка)

payload = TEXT

checksum = 2HEX ; опционально, вычисляется по алгоритму раздела 3.2

Поля разделяются вертикальной чертой (|). Пример корректного сообщения:

SOS|1|SYNS|42||12|Привет, красавица|3E

Поле flags может быть пустым (означает отсутствие дополнительных флагов). Присутствие флага A (ACK) указывает на подтверждение предыдущего сообщения, F (FIN) — инициирование завершения, R (RST) — аварийный сброс.

Поле checksum может отсутствовать; в этом случае получатель вычисляет его самостоятельно. При несовпадении вычисленного значения с переданным (или при отсутствии поля, если сторона ожидает его) сообщение должно быть обработано в соответствии с разделом 5.

3.1 Поля сообщения

  • start-tag — сигнатура протокола. Позволяет отличить SOS-сообщение от обычного текста.

  • version — версия протокола. Текущая версия — 1.

  • state — текущее состояние отправителя на момент отправки. Используется для синхронизации автоматов.

  • session-id — идентификатор сеанса, назначаемый инициатором. Целевой абонент обязан запоминать последние session-id для каждого инициатора и может анализировать их монотонность. Нарушение монотонности (уменьшение session-id или повторное использование) должно рассматриваться как аномалия и может приводить к переходу в состояние SUSP.

  • flags — битовые флаги, определяющие специальную обработку.

  • payload-length — фактическая длина полезной нагрузки в символах. Не должна превышать 160 за вычетом длины заголовка, однако точные ограничения зависят от реализации.

  • payload — текст сообщения. Может содержать управляющие последовательности (раздел 4).

  • checksum — контрольная сумма, вычисляемая по алгоритму, описанному ниже.

3.2 Контрольная сумма

Для обеспечения целостности сообщения и, как следствие, уменьшения вероятности неверного истолкования, используется следующий алгоритм вычисления контрольной суммы:

  1. Полезная нагрузка разбивается на слова. Словом считается непрерывная последовательность символов, не содержащая пробелов.

  2. Вычисляется произведение длин всех слов. Если полезная нагрузка не содержит слов (пустая строка или только пробелы), произведение считается равным 1.

  3. Из полученного произведения вычитается общее количество пробелов в полезной нагрузке.

  4. Результат берётся по модулю 256.

Контрольная сумма передаётся в виде шестнадцатеричного числа от 00 до FF. Алгоритм выбран за его простоту и устойчивость к случайным изменениям: даже замена одного символа с высокой вероятностью изменит произведение длин слов или количество пробелов.

Примечание: выбор алгоритма обусловлен необходимостью обеспечить достаточную энтропию при минимальных вычислительных затратах на стороне абонентского устройства.

4. Управляющие последовательности

Для повышения эффективности обмена и снижения риска неоднозначного толкования протокол определяет набор управляющих последовательностей, которые могут появляться в полезной нагрузке и интерпретироваться как команды или эмоциональные маркеры. Использование последовательностей не является обязательным, но их применение настоятельно рекомендуется.

Последовательность

Значение

Y

Согласие, положительный ответ. В соответствующем контексте — указание на определённые жидкости или физические атрибуты.

N

Отказ, отрицательный ответ.

...

Пауза, размышление, ожидание.

:-)

Доброжелательный намёк, отсутствие скрытых смыслов.

;-)

Намёк с двойным дном, требующий уточнения или предполагающий игривый подтекст.

:‑D

Смех, одобрение.

^_^

Радостное подтверждение, одобрение.

>_<

Смущение, лёгкое разочарование.

~

Волнообразная интонация, многозначительность.

(.)(.)

Указание на определённые физические атрибуты; использование требует явного контекста.

¯\_(ツ)_/¯

Неопределённость, несоответствие ожиданиям, уход от ответственности.

Протокол не требует обязательной интерпретации этих последовательностей, однако их использование способствует взаимопониманию. При реализации приложений рекомендуется распознавать данные последовательности и, в зависимости от контекста, предпринимать соответствующие действия (например, автоматически отправлять подтверждение на Y или ^_^).

5. Протокольный автомат

Протокол реализует конечный автомат, определяющий допустимые действия сторон в зависимости от текущего состояния. Каждая сторона поддерживает собственный автомат; синхронизация достигается за счёт обмена сообщениями и согласования полей state и flags.

5.1 Состояния

Код

Полное имя

Описание

IDLE

IDLE

Начальное состояние. Сеанс не активен.

SYNS

SYN-SENT

Инициатор отправил приглашение, ожидает ответа.

SYNR

SYN-RCVD

Целевой абонент получил приглашение и ответил согласием.

ESTD

ESTABLISHED

Сеанс установлен, идёт обмен полезными нагрузками.

FINW

FIN-WAIT

Сторона инициировала штатное завершение, ожидает подтверждения.

PRMT

PREMATURE

Преждевременное завершение (таймаут, RST, аномалия).

BUSY

BUSY

Целевой абонент временно не может принять сеанс.

SUSP

SUSPICIOUS

Обнаружены аномалии (нарушение монотонности, подозрительная активность).

CLSD

CLOSED

Сеанс завершён, ресурсы освобождены.

MORE

MORE

Запрос на продолжение сеанса после получения FIN.

5.2 Переходы

Основные переходы между состояниями описываются следующим образом (все события подразумевают отправку или получение SOS-сообщения):

  • IDLE → SYNS: инициатор отправляет сообщение с состоянием SYNS (флаги не установлены). Устанавливается таймаут ожидания ответа (рекомендуется 10 минут).

  • SYNS → ESTD: при получении ответа с состоянием SYNR и флагом A, а также совпадающим session-id.

  • SYNS → PRMT: при истечении таймаута или получении RST.

  • SYNR → ESTD: после отправки подтверждения и получения первого сообщения в состоянии ESTD.

  • ESTD → FINW: сторона отправляет сообщение с флагом F (FIN). После отправки устанавливается таймаут (рекомендуется 2 минуты).

  • FINW → CLSD: при получении подтверждения FIN (сообщение с флагом A, отражающее получение FIN).

  • FINW → MORE: если сторона, получившая FIN, не желает завершать сеанс, она может ответить сообщением с состоянием MORE и флагом A (подтверждение получения FIN, но отказ от завершения). В этом случае инициатор FIN, получив MORE, переходит обратно в ESTD.

  • MORE → ESTD: после отправки MORE и получения подтверждения (любое сообщение с флагом A) сторона переходит в ESTD.

  • MORE → CLSD: если на MORE не получен ответ в течение таймаута (10 минут), сторона переходит в CLSD.

  • Любое состояние → PRMT: при получении RST или истечении таймаута, за исключением явных завершающих переходов.

  • IDLE → BUSY: целевой абонент может ответить на SYN сообщением с состоянием BUSY, указывая на временную недоступность. Инициатор при получении BUSY переходит в IDLE и может повторить попытку через рекомендованный интервал (не менее 15 минут).

  • SYNR → SUSP: если целевой абонент обнаруживает нарушение монотонности session-id от данного инициатора (например, получен session-id меньше предыдущего) или несоответствие контрольной суммы.

  • SUSP → CLSD: после отправки RST и перехода в состояние CLSD. Сторона, получившая RST из SUSP, также переходит в CLSD.

5.3 Таймауты и пенальти

  • Таймаут ответа на SYN: 10 минут. При превышении инициатор переходит в PRMT.

  • Таймаут ответа в ESTD: 10 минут на каждое сообщение, требующее подтверждения (если флаг A не получен в течение этого времени, сторона переходит в PRMT).

  • Таймаут в FINW: 2 минуты. При превышении сторона переходит в CLSD.

  • Таймаут в MORE: 10 минут. При превышении сторона переходит в CLSD.

  • Пенальти для PRMT: сторона, перешедшая в PRMT, не может инициировать новый сеанс с тем же партнёром в течение 30 минут. При трёх последовательных переходах в PRMT с одним и тем же партнёром в течение 24 часов инициатор обязан добавить номер в локальный список «ненадёжные собеседники» и не инициировать сеансы в течение 7 дней.

  • Пенальти для BUSY: инициатор, получивший BUSY, должен выждать не менее 15 минут перед повторной попыткой.

  • Пенальти для SUSP: сторона, перешедшая в SUSP, отправляет RST и блокирует любые сообщения от данного инициатора на 24 часа.

6. Коллизии и ошибки адресации

В процессе работы протокола могут возникать ситуации, требующие специальной обработки.

6.1 Коллизия контекстов

Если целевой абонент получает SYN-сообщение от инициатора, с которым уже установлен активный сеанс (состояние ESTD), он должен ответить сообщением с состоянием BUSY, указав в полезной нагрузке причину «сеанс уже активен». Инициатор при получении BUSY обязан перейти в IDLE и повторить попытку после паузы.

6.2 Коллизия флагов

Если сообщение содержит недопустимую комбинацию флагов (например, одновременно FIN и RST), оно должно игнорироваться, а отправитель переводится в PRMT.

6.3 Коллизия управляющих последовательностей

При обнаружении в полезной нагрузке двух или более управляющих последовательностей, противоречащих друг другу (например, Y и N в одном сообщении), получатель должен интерпретировать это как «неопределённость» и может ответить последовательностью ¯\_(ツ)_/¯.

6.4 Ошибки адресации

  • Получение SOS-сообщения от незнакомого номера без предварительного SYN (т.е. не в состоянии SYNS или SYNR) должно обрабатываться как ошибка адресации. Получатель отправляет RST с полезной нагрузкой «не по адресу».

  • Если сообщение приходит с session-id, не соответствующим истории сеансов с данным отправителем (например, session-id меньше предыдущего или повторно использует значение из более раннего сеанса без монотонного роста), получатель переходит в состояние SUSP и отправляет RST.

6.5 Коллизия session-id

Совпадение session-id у разных инициаторов не является коллизией, поскольку идентификаторы уникальны в контексте пары «инициатор–целевой абонент». Однако если один и тот же инициатор использует session-id, уже применявшийся ранее к другому целевому абоненту, это считается нарушением монотонности и ведёт к переходу в SUSP.

7. Безопасность и устойчивость

Протокол SOS не предоставляет встроенных механизмов шифрования; конфиденциальность содержимого не гарантируется. При необходимости защиты передаваемых данных рекомендуется использовать внешние средства сквозного шифрования (например, предварительный обмен ключами через защищённые каналы).

Протокол устойчив к внешним ограничениям: он функционирует исключительно через инфраструктуру сотовой связи и не требует доступа к сети Интернет. В условиях, когда доступ к определённым мессенджерам может быть ограничен, SOS остаётся работоспособным.

Идентификаторы сеансов и механизмы контроля монотонности позволяют сторонам выявлять аномальное поведение (попытки повторного использования старых сеансов, слишком частые инициализации) и принимать защитные меры.

8. Нормативные ссылки

9. Заключение

В настоящем документе описан протокол SOS, предоставляющий надёжный механизм для установления, поддержания и завершения сеансов интимного общения текстового характера через SMS. Протокол использует формализованные сообщения, конечный автомат, управляющие последовательности и механизмы подтверждения, что позволяет сторонам избежать неопределённостей, свойственных неструктурированной переписке.

Будет ли этот RFC принят IETF или останется лишь локальным стандартом — покажет время. Возможно, вы уже используете его, сами того не подозревая. А возможно, после прочтения этой статьи захотите внедрить его в своём следующем проекте. В любом случае, теперь у нас есть общий язык для описания процессов, которые раньше приходилось объяснять «на пальцах».