We need to change the protocol

[m1kc]

Our protocol is not the best in the world. We must fix this as soon as possible.

[m1kc]

Итак, давайте подумаем. Какие задачи стоят перед протоколом XSP? Ну, самая общая задача - передавать информацию самого разного рода. Если более конкретно:

1. Передача строк. Можно обойтись и одной, но лучше - несколько в одном пакете.
2. Передача цифр. Для координат мыши, для параметров звука и так далее.
3. Передача файлов и звука, иначе говоря - произвольных байтовых потоков.
4. Поскольку всё это может передаваться одновременно, ни одна задача не должна надолго блокировать канал. Иначе говоря, XSP должен уметь либо разбивать данные на пакеты (и делать это достаточно быстро для вещания в реальном времени), либо открывать несколько сокетов (и необходим грамотный механизм их открытия и закрытия).

[m1kc]

(13:39:32) Skynet: Блин. Мудрёно слишком. У меня другая идея. Она слегка отходит от изначальной, но зато достаточно простая и чем-то мне интересная. Сделать уровень выше над сокетом - канал. Плагины могу открывать каналы в том количестве, котором надо. Канал - это тоже I/O Stream, в который можно писать и читать, вроде, непрерывно. Но! Когда ты пишешь в такой канал, то оно потом собирается в пакет (по вызову flush) уходит по проводу. Приходит и лезет в InputStream, с которого можно читать как быдто просто из сокета. То есть модель такая, что каналов много, а сокет один. И мы реализуем простой протокол, который как нити толстой верёвки скручивает в один и передаёт по проводу, а на том конце распутывает.

[m1kc]

У меня вот такая идея появилась. Допустим, у нас есть некий командный протокол. Пусть даже в XML, похуй. Есть протокол передачи файлов. Есть протокол передачи звука. И т.д. Далее. Любой модуль может в любой момент потребовать открытия сокета. Но! Этот сокет не будет связан с этим модулем. Проще говоря, любой модуль может в любой момент воспользоваться любым сокетом, если он не используется прямо сейчас кем-то ещё. Разумеется, это касается в основном командного сокета, вряд ли кто-то будет передавать звук в канале, открытом для файлов.

Но это сторона 1. Что же происходит на стороне 2? Сторона 2 вообще не в курсе, зачем открыт сокет. Потребовали — открыли. И эта сторона после открытия готова принимать оттуда любую информацию по любому из протоколов.

Что нам это даёт?

1. Можно свободно пользоваться общим командным сокетом.
2. Можно не беспокоиться о том, какой сокет какому модулю принадлежит — вторая сторона в любом случае обработает всё правильно.
3. Можно позволить одному модулю открыть несколько сокетов. Или не открывать их вовсе. Или открывать столько, сколько надо, время от времени.

Собственно, это решает проблемы и с модульностью, и с откpытием сокетов, и с одновременной передачей файлов.

[m1kc]

Переосмыслил предыдущую идею. Пусть у нас будет командный сокет и — остальные — трансляционные сокеты. Смысл трансляционного сокета в следующем: когда он открывается, я вызовом readUTF() получаю его тип; если тип мне незнаком, я просто закрываю сокет, если же знаком, то отдаю этот сокет тому модулю, за которым закреплён данный тип, и дальше по нему могут идти любые байты. Ну и, конечно, нужно иметь возможность ещё по командному протоколу проверить, смогу ли я обработать этот тип трансляции или нечего даже пытаться.

[solkin]

А не проще ли не перебирать сокеты, а открыть сокет и отправить нужный тип? Тогда удалённая сторона поймёт, что от ней хотели и ты сразу можешь этот сокет перебрасывать в нужный модуль.

[m1kc]

Ну, а у меня как?

[solkin]

Ты не написал, кто передаёт тип, а кто его читает.

[m1kc]

Передаёт открывающий, читает принимающий. Очевидно же.

[solkin]

Тогда да, это хорошая тема. Но кроме типа нужно ещё передавать версию плагина.

[m1kc]

Ты предлагаешь плагину версии 15 помнить, что умеют и что не умеют предыдущие 14 версий?

[solkin]

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

[m1kc]

А. Ну, можно и так.