Путь джедая прям...

В релейтедах твоя же тема от 2013 года с тем же вопросом %)

Может, бросить его уже, удава этого и что-то другое взять для вебсокетов? )

Предлагаю без микрофреймворка. Умеет не только gevent.

В релейтедах твоя же тема от 2013 года с тем же вопросом

Нихрена себе :( Мда, этот gevent оказался миной замедленного действия.

Может, бросить его уже, удава этого и что-то другое взять для вебсокетов? )

Похоже, всё идёт к тому что я таки закопаю питон в пользу js или его производных. Только у меня много питоновского кода, прямо сейчас соскочить не готов.

Предлагаю без микрофреймворка.

Я над этим активно думаю. Похоже, всё идёт к этому, хотя очень бы хотелось какой-нить flask или bottle, очень привык к ним.

Можно совмещать. Часть кода на питоне, часть на js(там где нужны вебсокеты).

Ну тогда можно вынести ws в отдельный интерфейс и забиндить его с нодом&socket.io :)

Есть готовые решения, интегрирующие uwsgi-вебсокеты в тот же flask. https://github.com/zeekay/flask-uwsgi-websocket например. Оно не привязано к gevent, может native uWSGI async и блокирующий API (с прицелом на треды/процессы) вместо него.

Или можно запускать отдельным процессом на той concurrency model, которая нравится, и привязывать к рауту снаружи flask/bottle.

threading.Timer — странная вещь для вебсокета. Ты хочешь спаунить ещё по одному треду на каждого клиента? Обычно пользуют что-то асинхронное.

Брось уже эту py3каку.

Есть готовые решения, интегрирующие uwsgi-вебсокеты в тот же flask

Спасибо, уже копаю. Похоже что это самый прямой путь.

threading.Timer — странная вещь для вебсокета.

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

Тогда я бы поднимал вебсокеты в отдельном процессе. Хотя ты можешь хотеть другого.

flask-uwsgi-websocket например

ОМГ, ты не поверишь, оно на gevent. Чтоб они все горели в аду. Всё идёт к тому что я перепишу Timer с использованием примитивов gevent. Это пол часа работы максимум, а я уже два дня развлекаюсь с различными форками gevent и сопутствующими библиотеками.

Тогда я бы поднимал вебсокеты в отдельном процессе.

Не хотел городить вебсокеты на отдельном порту. В мире 100500 дурных проксей и фаерволов которые это не пропустят. Я бы сам в это не поверил если бы постоянно с этим не сталкивался во всяких универах, публичных вай-фаях итп.

ОМГ, ты не поверишь, оно на gevent.

Дефолт

from flask import Flask
from flask.ext.uwsgi_websocket import GeventWebSocket

app = Flask(__name__)
websocket = GeventWebSocket(app)

@websocket.route('/echo')
def echo(ws):
    while True:
        msg = ws.receive()
        ws.send(msg)

if __name__ == '__main__':
    app.run(gevent=100)

на gevent. А если так:

from flask import Flask
from flask.ext.uwsgi_websocket.websocket import WebSocket

app = Flask(__name__)
websocket = WebSocket(app)

@websocket.route('/echo')
def echo(ws):
    while True:
        msg = ws.receive()
        ws.send(msg)

if __name__ == '__main__':
    app.run()

Или так:

from flask import Flask
from flask.ext.uwsgi_websocket.async import AsyncWebSocket

app = Flask(__name__)
websocket = AsyncWebSocket(app)

@websocket.route('/echo')
def echo(ws):
    while True:
        msg = ws.receive()
        ws.send(msg)

if __name__ == '__main__':
    app.run()  # но я не помню, что писать прямо в app.run, чтобы указать число native async-worker'ов

то оно станет uwsgi native async.

Не хотел городить вебсокеты на отдельном порту.

А зачем на отдельном порту? uwsgi может прокинуть любой раут на вебсокеты. nginx тоже может прокинуть любой раут на другое uwsgi-приложение с вебсокетами.

Tornado же, ну.

микрофреймворк

Ну, он достаточно минималистичен, в общем-то.

А чем не угодил http://websocketd.com?

socket.io

Нодеры как всегда вякают невпопад.

если socket.io лучший среди всех языков и платформ, то почему бы и не предложить? может человек догадается, что Python для таких дел не писался и все что на нем есть это унылые костыли

Я поковырял несколько часов этот uwsgi. Похоже, что async-mode требует всяких greenlet или чего-то похожего: http://uwsgi-docs.readthedocs.org/en/latest/Async.html .

И это печально, всё что мне нужно это тупо raw socket, остальное я могу сделать сам. Реально лажа какая-то, хоть прям садись и пиши свой wsgi-сервер. Либо как-то извращяться c uwsgi.connection_fd() . Что я щас и попробую.

А чем не угодил http://websocketd.com?

Я так понял это враппер для oneshot-скриптов, а у меня мультипоточное stateful приложение.

Советуешь явное решето.

Можно развёрнутее? В uwsgi нашли дырки?

если

Vert.x + Jython https://github.com/vert-x/vertx-examples/blob/master/src/raw/python/websocket...

Часть кода на питоне, часть на js(там где нужны вебсокеты).

так можно и на питоне отдельно ws вынести, на том же asyncio(а ещё если и обертку для вебсокетов найти) это не так трудно делается

так можно и на питоне отдельно ws вынести

Так и сделаю. Всем спасибо за помощь.

Я в мае нашел у них мега дырень

https://github.com/unbit/uwsgi/pull/910

Для Ъ - аутентификация клиентов по SSL сертификатам не работала, сервер пропускал с любым сертификатом. Причем, уязвимость была с самого начала, и незаметить ее можно было только, если ее ни разу не тестировали. Ну и самое интересное - в апстриме уязвимость пофиксили сразу, а вот до дистрибутивов до сих пор добирается - в федоре закрыли уязвимость только пару недель назад, а в дебианах и убунтах uwsgi до сих пор дырявый.

Ну и когда я по их коду лазил, там еще претензии были (в плане SSL) - авторы сдирали код с nginx, только нормально сделать это не осилили.

Естественно, не тестировали: uwsgi часто стоит за nginx. Я не знаю, нафиг деплоить uwsgi без nginx.

Плюс клиентские сертификаты — не настолько популярная фича, да ещё и в контексте вебсокетов.

Жесть, нет слов. Тесты? Не, не слышал.

Tornado

Можно впилить Tornado в дополнение к тому что есть и повесить его на другой location в nginx. https://github.com/hiroakis/tornado-websocket-example/blob/master/app.py

Есть ещё такое извращение, но не уверен, что оно нормально работать будет: http://mike.depalatis.net/using-websockets-with-flask-via-tornado.html

Сервер http://aiohttp.readthedocs.org/en/stable/web.html?highlight=websocket#websockets

Клиент http://aiohttp.readthedocs.org/en/stable/client_websockets.html?highlight=web...

http://www.gorillatoolkit.org/pkg/websocket

Спасибо, интересная штука. А ты её уже использовал? Как впечатления?

Да. Работает хорошо. Изначально вебсокеты делал через aiopyramid, но лучше их отделять от основного приложения. Теперь вебсокеты на aiohttp, на отдельном порту.

Вебсокеты - асинхронщина. Значит tornado или aiohttp. Или долгий и скучный секс с gevent.

Ну или http://eventlet.net/doc/modules/websocket.html.

А javascript писался для node.js и вебсокетов? Лол.

А вобще я тоже за socket.io и вовсе не обязательно его использовать на ноде. У меня к примеру хаскеллное приложение через него работает.

Вебсокеты - асинхронщина.

Вебсокеты это обычные сокеты. Всё что мне нужно это файловый дескриптор с которым работать. Меня вполне бы устроила обработка в отдельном треде без всяких адовых костылей типа gevent. Ну или на худой конец asyncio. В итоге остановился на aiohttp.

Есть вот такая штука - https://github.com/mosquito/wsrpc, глянь может оно то что тебе надо.

чем, кстати, проблема решилась ? есть тут у меня один чатик аснхронный, думаю переписать и в портфолио кинуть

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

Щас изучаю js. Конкретно, присматриваюсь к jquery easy ui и angular.

Я боюсь tornado, лет 8 назад писал джаббер-сервер на коллбэках, а там протокол такой что сплошные состояния. Проклял всё на свете. На js как-то с коллбэками приятнее работается.

Использую aiohttp

так и думал на него перекатиться, когда делал, то ли мимо глаз пропустил, то ли не было его

В итоге не понадобился шаблонизатор

я кстати, когда чатик пилил, тоже думал прикрутить фреймворк, хотя бы для авторизации, в итоге одним JSом обошёлся

Эта штука в тредах методы вызывает, которые ты из JS дергаешь, и отдает тебе в JS результат. С каллбэками она сама разбирается. Но вообще в торнаде еще с 3-й версии нормально на concurrent.Future'сах вся эта callback-лапша прячется.

То что там торнада с асинхронщиной под капотом тебе даже знать не обязательно).

concurrent.Future

Честно говоря, я до сих пор не понимаю что это. Вообще. Издалека выглядит как threadpool работающий над очередью заданий. Но тогда не понятно чем это лучше тредов. Можешь рассказать?

Всё что мне нужно это файловый дескриптор с которым работать

Ты хочешь вручную куячить протоколы поверх байтового потока?

Ты хочешь вручную куячить протоколы поверх байтового потока?

Конечно нет, просто я уже не жду такого от фреймворков. Мои следующие вопросы которые я скоро задам:

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

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

Зачем для этого вебсокеты? Ты пытается сделать некий RPC, но чем RPC поверх вебсокетов лучше, чем RPC поверх HTTP?

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

Для push notifications. Я ещё рассматривал long polling (comet?), но решил что это слишком костыльно. Возможно, я ошибаюсь. Потом, нативной нормально поддержки comet я тоже не видел, «спасибо» синхронному wsgi.

Вот и решил что мне проще свести задачу «написать tcp-сервер», чем возиться с кривыми хаками фреймворков. Потому что в серверах я хоть что-то понимаю, кмк.

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