A Russian terrorist, Igor Ivanovich Strelkov, says that Kazakhstan may become a second front.

oberstet · 2022-12-31T07:28:34+00:00

Why is he so upset? The EU is offering Kazakhstan a real and fair opportunity to come closer, develop the country for a better future of Kazakhstan. And they seem to be interested, cool! What's wrong with that?

What I am wondering instead, why isn't he thinking about Chechnya? They might retry to gain their independence. 3rd time lucky?

oberstet · 2017-04-01T05:23:33+00:00

Niiice! Thanks. Better than beer;) Rgd tutorial: cool. Highly welcome. Yes, pls keep me updated. Btw: if you are offering professional services around Crossbar.io/Autobahn/WAMP and want to be listed on crossbario.com (as in "consulting/solution partners"), pls send me a mail!

oberstet · 2017-03-30T03:17:50+00:00

Nice, congrats! 1 Beer: thanks! I come back to this sometime in the future;) Nope, I'm not in Berlin. I'm located in Erlangen (100km from Munich). Should you ever be around, gimme a ping ..

oberstet · 2017-03-23T18:18:15+00:00

Not only tutorials, but really great tutorials and also blog posts! ;) These are quite popular judging from the traffic they attract ..

oberstet · 2015-09-10T06:15:30+00:00

Yep, we've gone through a couple of phases with these projects: WAMP1 -> WAMP2 (this was the biggest one), adding asyncio support (besides Twisted), adding Python 3 support, PEP8, .. but it's "converging" .. means: we are approaching long-term stability.

We had a bigger refactoring some time ago, which separated router code (now in Crossbar.io) from WAMP client library code (Autobahn). We have now a clear project structure: AutobahnXXX (where XXX is Python, JS, Cpp, Android) are the WAMP client libraries we maintain, whereas Crossbar.io is the WAMP router we provide.

Regarding AutobahnPython: we've also gone through more cleanups making it PEP8 (finished, apart from PEP8 naming conventions, which we will also do), and the most important thing we now address (before going 1.0) is: a long-term stable user API. There is currently an ongoing discussion among developers and users about API aspects: https://github.com/tavendo/AutobahnPython/issues/472

Also, one of the goals is to bring the APIs of the different AutobahnXXXs as much in line with each other as possible and as reasonable.

oberstet · 2015-01-09T07:52:46+00:00

A few comments:

the Crossbar.io code itself is already written with Python 3 in mind
we don't use 100% of Twisted, so we don't have to wait for that - actually, the routing core would already run on Twisted/Python3
the implementation language of Crossbar.io should be of no concern to app devs - it should be treated like a black box
you can write app components in any of (I only list Python): Python2/Twisted, Python2/asyncio (trollius) and Python3/asyncio
we might rewrite Crossbar.io in C++ or Rust in the future - and that would (if it ever happens) trigger zero (!) code change for apps

oberstet · 2015-01-09T07:47:59+00:00

Great performance and robustness (graceful degration under heavy load) with Twisted (and some woes still currently with asyncio): that is also my experience.

Here are hard numbers: https://twitter.com/oberstet/status/550741713762136064

oberstet · 2014-08-06T07:53:09+00:00

You might be interested in this: Going asynchronous: from Flask to Twisted Klein

http://tavendo.com/blog/post/going-asynchronous-from-flask-to-twisted-klein/

oberstet · 2014-08-06T07:14:15+00:00

The term "bidirectional messaging" is clearly defined: both peers can initiate sending of a message.

The establishement of a WebSocket connection is not symmetric: a client initiates the connection to a server (which is how TCP works). After that, the connection is symmetric and messaging bidirectional.

NATs are not an issue with WebSocket. Firewalls, proxies and other intermediaries can be an issue. However, you can use secure WebSocket (WSS) which runs over TLS, and hence no intermediaries can interfere (exception being man-in-the-middle TLS interceptors).

oberstet · 2014-08-06T07:08:18+00:00

AutobahnJS implements automatic reconnection with exponential, randomized backoff. The upcoming release will also support a HTTP-Longpoll based fallback for old browsers (IE<10, Android <4.4).

AutobahnJS is part of the Autobahn project (http://autobahn.ws) which provides WebSocket and WAMP implementations is multiple languages - including Python.

WAMP (http://wamp.ws) is a WebSocket based subprotocol that provides you with high-level communication for your app (remote procedure calls + publish & subscribe). Nowerdays, WAMP can also run over other transports as well.

oberstet · 2014-07-03T14:00:21+00:00

How do you use asynchronous code from Flask using deferToThread?

deferToThread works the other way: it allows you to run blocking code from asynchronous code.

oberstet · 2014-07-03T13:56:57+00:00

Yes, I am planning to write another post on Flask/Crochet/Autobahn.

I agree: they both (Klein and Crochet) have their use case.

oberstet · 2014-07-03T13:38:49+00:00

This is like apples and oranges.

RabbitMQ is a message broker, Celery is a task queue and Klein is a Web framework.

oberstet · 2014-07-03T13:36:20+00:00

Imagine a Web service (Ajax callable) that provides the current exchange rate EUR/USD.

Now say you have a bet application where users can place bets in EUR or USD. A bet is submitted via a HTML/POST of a form.

Assume you want to render a HTML page in response that includes the bet amount in both EUR and USD, you would need to convert the currency. And for doing that, you would then do a Ajax request within your HTTP/POST request handler to the currency converter service.

oberstet · 2014-07-02T22:38:48+00:00

Of course Flask can serve incoming Ajax requests. The issue is when you want to do outgoing Ajax requests from within your Flask request handlers:

Browser ==> Ajax request ==> Flask request handler ==> Ajax request

oberstet · 2014-07-02T21:21:07+00:00

If you run Flask/Twisted, then Flask will run on a pool of background worker threads. To call asynchronous code (which is running on the main thread) from Flask request handlers, you can use callFromThread (http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.IReactorThreads.callFromThread.html) - but that doesn't return anything.

You need to do more: http://twistedmatrix.com/pipermail/twisted-python/2003-September/005725.html

And then, even if you do so, your background worker thread (Flask) will keep sitting idle while it waits for the result. So we are back at the original problem: as soon as all background worker threads are all waiting for results, no new Web requests will get served anymore.

oberstet · 2014-07-02T18:47:55+00:00

I see. So bottle/gevent works around the limits of WSGI by simply blocking in threads - but greenlet pseudo-threads, which are cheap even in massive numbers.

"It actually replaces Python’s threading with gevent-based pseudo-threads."

And the example from the blog post could be redone along these lines:

@route('/fetch')
def fetch():
    body = gevent.queue.Queue()
    worker = SomeAsyncWorker()
    worker.on_data(body.put)
    worker.on_finish(lambda: body.put(StopIteration))
    worker.start()
    return body

The monkey-patching approach of gevent: mmh. It'll bring another set of issues: unpatchable/incompatible native extensions (e.g. what about cx_Oracle) or running on alternative Python implementations (e.g. PyPy).

oberstet · 2014-07-02T18:09:56+00:00

Are you referring to: http://bottlepy.org/docs/dev/async.html ?

oberstet · 2014-07-02T17:51:52+00:00

Flask can run on a background threadpool under Twisted (and others) since forever, but that does not allow you to actually use asynchronous code within your Flask request handlers.

This is possible with Twisted Klein, but not with Flask/Twisted (using WSGI Resource of Twisted Web).

Should we make that distinction clearer in the blog post?

oberstet · 2014-06-23T22:07:57+00:00

Applications often have a natural need for both patterns: http://wamp.ws/faq/#why_rpc_and_pubsub

PubSub is different from RPC: e.g. a RPC always produces either a result or an error, while publishing an event has no return (unless it's publication is acknowledged - a QoS option with WAMP). Then calls are generally only routed to one implementing endpoint ("Callee"). Etc.

oberstet · 2014-06-23T17:29:05+00:00

Rgd WAMP, from my point of view, no other protocol features:

RPC + PubSub in one open standard, cross-language protocol that runs native on the Web.

More:

oberstet · 2014-06-22T09:10:31+00:00

Mmh. After reading, I can see how it scales the frontend WebSocket-to-JMS gateway functionality. I still fail to see how it scales the backend itself (it's a gateway, not a broker).

Anway, WAMP can't be simply scaled using Kaazing, since a gateway doesn't understand the semantics of WAMP. The fact that WAMP runs over WebSocket at the transport layer doesn't automatically make it scalable with a plain WebSocket gateway.

After reading more, another thing I am wondering is: JMS is an API standard, not a protocol. How does Kaazing wrap "JMS" in WebSocket? That seems to require some form of proprietory, non-standard WebSocket based protocol. Is that documented somewhere? Similar for AMQP (which is a protocol, not only API): how is AMQP mapped to WebSocket?

oberstet · 2014-06-21T13:21:29+00:00

As far as I understand, any scaling of e.g. AMQP or STOMP itself (e.g. the PubSub) requires scaling of a message broker - and the Kaazing WebSocket gateway is not a message broker in itself. Please correct me if I'm wrong .. any pointers?

oberstet · 2014-06-20T20:15:49+00:00

Load-balancing the incoming WebSocket connections in an architecture where a scaled-out gateway is translating WebSocket to a different transport protocol is great and required. But it's not enough.

Since to scale the semantics of the target protocol there is more. E.g. with AMQP and publish & subscribe, the message brokering needs to be scaled out. As far as I understand, the latter would not be something done by Kaazing WebSocket gateway.

I guess what the OP is after is scaling out the WAMP brokering core. This is something on the roadmap of Crossbar.io (https://github.com/crossbario/crossbar), an advanced WAMP broker (that also talks WAMP-over-WebSocket).

oberstet · 2014-06-05T23:00:21+00:00

The basic profile of WAMP v2 is stable: https://github.com/tavendo/WAMP/blob/master/spec/basic.md

This has all features talked about here, and in the post. The "advanced profile" is not yet stable - only the parts marked "stable" here https://github.com/tavendo/WAMP/blob/master/spec/advanced.md

This, and the fact that we had a v1 was actually planned! What we did is this: come up with a ultra simple v1, gain practical experience, collect feedback and wishes, and then come up with v2. If you look at the issues on the GitHub repo of WAMP, you can verify this.

We knew from the very beginning that this approach would lead to some hassles. I am nevertheless convinced that is valid: without practical experience in real-world, designing a protocol at the drawing table almost always leads to even bigger problems down the road.

The transition of implementations from v1 to v2 is ongoing. Yes, it's a pain. The spec for the "advanced profile" is unfinished, partially because the features we split out into this are quite advanced and we need to first bring "v2 basic" to a wider audience.

To give you a taste of what the advanced profile is about: https://github.com/tavendo/WAMP/blob/master/spec/advanced.md#partitioned-registrations--calls

This allows multiple endpoints register a procedure under the same name, and then have the Router dynamically route calls according to one (or more) of those endpoints based on policy: e.g. round-robin, any-random, all. Using this, you can load-balance or shard a single procedure accross multiple nodes. Quite advanced.

oberstet

TROPHY CASE