On Dec 13, 2013, at 7:09 AM, Tobias Oberstein <tobias.oberst...@tavendo.de> wrote:
>>> I am working on Twisted Endpoint support in Autobahn >> https://github.com/tavendo/AutobahnPython. >> >> Yay! > > Endpoints are cool. > > FWIW, here is a working example of WebSocket I tested over both Unix domain > sockets and the usual TCP/TLS endpoints: > > https://github.com/tavendo/AutobahnPython/tree/master/examples/websocket/echo_endpoints > > This works with all features Autobahn provides like support for different > WebSocket versions (Hixie-76, RFC6455) and > WebSocket extensions (like permessage-compression with deflate, snappy, > bzip2). Cool! > > Sure. Can I use: > > "autobahn.websocket"? > > Since Autobahn also provides other protocols (WAMP), and .. Sure. > endpoint = serverFromString(reactor,"autobahn.websocket: > tcp:80:url=ws://myhostname.com/somepath") > > Here, a single endpoint descriptor is specifying parameters for both > WebSocket, and the underlying transport. > > Underlying transport: > tcp:80 > > WebSocket overlay: > autobahn.websocket:url=ws://myhostname.com/somepath:extensions:permessage-deflate;permessage-snappy > > So the plugin needs to parse not only the "overlay transport" spec, but also > the underlying spec ("tcp:80") and all variants thereof? > > Or can I let the existing Twisted machinery do the parsing of the underlying, > and only parse off the remaining > stuff > ("url=ws://myhostname.com/somepath:extensions:permessage-deflate;permessage-snappy" > in this case) There's some discussion of this here: <http://twistedmatrix.com/trac/ticket/5642>. It's probably possible, the rules are reasonably simple. > > And if not, does that mean not only the endpoint main identifier ("tcp" vs > "unix" vs "autobahn.websocket") must > be non-overlapping, but also all the individual parameters? Nope; the first one has to be non-overlapping, then you just have to decide on a definite place where the "wrapped" endpoint begins. > Like in the case for WebSocket, there is a need > for a "url" parameter. > > These Qs have brought me to .. > > > Variant 2) > > endpoint = serverFromString(reactor, "tcp:80") > wrappedEndpoint = serverFromString(reactor, endpoint, > "autobahn.websocket:url=ws://myhost.com/mypath") > > where I would start a program like > > python myprog.py --transport "tcp:80" --wrappingTransport > "autobahn.websocket:url=ws://myhost.com/mypath" > This variant is worse because you can't change the command lines of other twistd plugins, which might be able to use websockets unchanged if you could just get it returned by serverFromString. > Is there such thing as a WrappingEndpoint? Not yet, no. Comment on that ticket :). > == > > This is yet another topic/question, but it fits here. > > Twisted has defined interfaces for both stream (and datagram transports). > > WebSocket is essentially a bidirectional, reliable, ordered datagram > transport (with 2 payload types: binary and utf8). > > Is there a Twisted Interface for such transports? No. Websockets are incredibly bizarre; most protocols support either arbitrarily typed data or just bytes/just text. The hybrid weirdness of "binary" (with no additional type information) and "text" is unique. > I am asking, since I am right now also refactoring the code within Autobahn > that lays above raw WebSocket .. a PubSub+RPC protocol, that essentially only > assumes a transport like above. > > I want to make it independent of WebSocket and only assume a bidirectional, > reliable, ordered, datagram transport. You can do this with length prefixing, but arguably Twisted should have such an interface that can express this combination of concepts, because I think these are, technically speaking, the semantics of a UNIX datagram endpoint, but the required interface (actually a superclass, bleh) is the same as for UDP, implying unreliability. -glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
