микрофреймворк c поддержкой websockets не на gevent

чем RPC поверх вебсокетов лучше, чем RPC поверх HTTP?

Для push notifications.

Ну, если клиенту кровь из носу нужны нотификации от сервера, тогда да.

Вот и решил что мне проще свести задачу «написать tcp-сервер»

Мне не кажется, что сваливаться на обмен блоками байтов - хороший выход. Понятие «ресурса» - полезное понятие.

Если я не прав то отговори меня.

Да не, попробуй. Будет кого спросить :)

сваливаться на обмен блоками байтов - хороший выход

Я абсолютно против этого. Я вообще считаю что потоки не нужны. Нужны как минимум сообщения. Я не понимаю почему этого никто не понимает. Вот выдержка из док по protobuf, например:

If you want to write multiple messages to a single file or stream, it is up to you to keep track of where one message ends and the next begins. The Protocol Buffer wire format is not self-delimiting, so protocol buffer parsers cannot determine where a message ends on their own.

Вот поэтому все и городят свои велосипеды. Накрайняк, первыми двумя байтами буду передавать длину сообщения и потом сообщения. Тогда можно будет относительно легко нарезать на стороне клиента.

PS самое фееричное что я видел это jabber. Оно работает поверх tcp такой хренью как «xml потоки». Я так и не понял как я должен нарезать поток на сообщения. В итоге городил костыль в виде цикла который принимает данные до тех пор пока xml-парсер не перестанет возвращать ошибку. Это помимо того что парсеры принципиально ожидают на вход только валидное xml-дерево с одним корнем, два сообщения подряд они не парсят. Поэтому, на случай двух и более ответов, я ответ сервера оборачивал в resp = «<sometag>%s</sometag>» % resp . Ты мне скажи, это я дурак или мир сошёл с ума?

сваливаться на обмен блоками байтов - хороший выход

Я абсолютно против этого. Я вообще считаю что потоки не нужны. Нужны как минимум сообщения. Я не понимаю почему этого никто не понимает. Вот выдержка из док по protobuf, например:

protobuf-сообщение - это тоже блок байтов. HTTP дает тебе понятие «ресурса» - в случае protobuf ты будешь как-то эмулировать эти ресурсы. Вопрос - оно тебе надо? При том, что protobuf-сообщения вполне можно передавать по HTTP :)

The Protocol Buffer wire format is not self-delimiting, so protocol buffer parsers cannot determine where a message ends on their own.

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

Ы? Насколько я понял Wikipedia, вебсокеты уже record-oriented.

В итоге городил костыль в виде цикла который принимает данные до тех пор пока xml-парсер не перестанет возвращать ошибку.

Я уже 15 лет не работал с XML, но вроде SAX-парсеры вполне умеют разбирать входной поток. Как только тег верхнего уровня закрылся - у тебя есть валидное XML-дерево.

Ты мне скажи, это я дурак или мир сошёл с ума?

Думаю, мой ответ тебе не понравится.

вебсокеты уже record-oriented.

Вот чёрт, я не знал :(. Это всё меняет.

вроде SAX-парсеры вполне умеют разбирать входной поток

Блин :)

mqtt и прочие mq?

SAX-парсеры вполне умеют разбирать входной поток

Я правильно понял что надо было при помощи SAX найти конец сообщения и скормить его нормальному пасеру чтобы получить DOM? До этого я тогда не додумался. Использовать же просто SAX для работы с документом мне кажется самоубийством.

Я правильно понял что надо было при помощи SAX найти конец сообщения и скормить его нормальному пасеру чтобы получить DOM?

Да. Не знаю, сработало бы это или нет, но начал я бы с этого.

1) какие есть либы для сериализации и валидации данных чтобы работали в питоне и js. Ну, типа protocol buffers, но может есть что-то более интересное. И чтобы умело нарезать (tcp) поток на сообщения.

json и msgpack. Второй быстрее, компактнее и умеет бинарные данные передавать нормально. Но реализации что под питон, что под JS пока сыроваты.

2) Есть ли для js надстройка для вебсокетов для организации надёжной доставки данных. Ну, чтобы, например, само возобновляло соединение при обрыве связи. Что-то типа очереди сообщений или message bus, не знаю как называется. Опять-таки, интересуют проверенные решения, а загуглить костыли на гитхабе я и сам могу (уже загуглил).

wsrpc линк на который я тебе кинул

типа protocol buffers

впрочем protobuf.js тоже ок выглядит... не знаю почему знакомый фронтендер про него плохо говорил...

Лучше тредов тем что не надо треды в ОС плодить. Вообще конкретно concurrent.Future это не совсем про то, это просто структура данных чтобы каллбэк и статус выполнения хранить-передавать...

Лучше тредов тем что не надо треды в ОС плодить.

Так concurrent.Future.ThreadPoolExecutor как раз и запускает треды ОС. Там нет никакой магии: https://hg.python.org/cpython/file/3.4/Lib/concurrent/futures/thread.py

Треды тут на самом деле немного сбоку.

The concurrent.futures module provides a high-level interface for asynchronously executing callables.

The Future class encapsulates the asynchronous execution of a callable.

Это просто структура данных, реализующая паттерн для упрощения написания асинхронного кода. Аналогично Deferred'ам из twisted.

Стандартные Future из python 3.2 можно использовать с тредами и процессами, да.

В торнаде есть свои, для использования с tornado.gen.coroutine.

В asyncio тоже свои, чуток отличаются, не thread-safe, но интерфейс одинаковый.

В wsrpc тебе это все не нужно, оно само будет с асинхронностью внутри сокетов разбираться и твои синхронные методы в threadpool'е вызывать. Это ведь именно то что ты хотел?