Re: [Twisted-Python] Reliable way to check if Twisted has IPv6 support?

[Phil Mayers]

On 13/12/13 03:22, Amit Saha wrote:


Is there a more reliable way (which works with the Twisted-8.0+) to check this?


Check the Twisted version.

You should also note that IPv6 features have appeared in multiple 
versions; HostnameEndpoint was added in 13.2.0 for example, whereas 
basic "connectTCP to IPv6 address" was added in 12.1.0, with listenTCP 
in 12.0.0


So:

import twisted

vt = (twisted.version.major, twisted.version.minor)

if vt > (13,2):
  def connectv6name(n):
return HostnameEndpoint(...)
elif vt > (12,1):
  def connectv6name(n):
d = myGetAddrInfo(...)
d.addCallback(reactor.connectTCP, ...)
else:
  def connectv6name(n):
raise Exception('twisted too old for IPv6')

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted Endpoints and WebSocket / Autobahn

[Glyph]

On Dec 12, 2013, at 12:29 AM, Tobias Oberstein  
wrote:

> Hi,
> 
> I am working on Twisted Endpoint support in Autobahn 
> https://github.com/tavendo/AutobahnPython.

Yay!

> So far, I made Autobahn able to talk WebSocket _over_ arbitrary Twisted 
> Endpoints, e.g. WebSocket over Unix domain sockets works. This is already 
> quite nifty.
> 
> Is there anything like Twisted Endpoints for Processes and/or Serial? Like:
> 
> endpoint = 
> serverFromString(reactor,"process:program=/usr/local/bin/myprogram")
> 
> or
> 
> endpoint = serverFromString(reactor,"serial:port=/dev/tty1:baudrate=115000")

Yes and no.

For serial port support, see .  For 
subprocess support, 
.

However, process support is unfinished, as you can see in 
; there still needs to be a string 
parser plugin, so you can't do what you suggest with serverFromString.

I hope you'll poke those tickets along through the process.

> That would allow to talk WebSocket over stdin/stdout to a program or a serial 
> conneced device. Both can be useful in certain situations.

And that would be awesome.

> I'd also like to add the other: creating an Twisted Endpoint _from_ an 
> Autobahn server/client to be able to talk any (stream) protocol _over_ 
> WebSocket (like SSH or VNC over WebSocket).
> 
> endpoint = 
> serverFromString(reactor,"websocket:tcp:80:url=ws://myhostname.com/somepath")

There's totally a plugin architecture for this, and I'm excited for you to use 
it :-).

One quick comment though: would you be OK with using 'autobahn' as your 
identifier rather than 'websocket'?  There are still plans to include basic 
websocket support within Twisted itself and it would be a shame to start 
conflicting on that identifier.

> I guess I need to provide an implementation of
> http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.ITransport.html
> 
> What else? Is there some docs or recipe?

Sadly it seems that although 
 alludes 
to the plugin API, it doesn't actually link to it.

The way that you add a new type of endpoint to the string parser is by 
registering a Twisted plugin (assuming that you know how to do that) providing  
 
.

Hopefully the API documentation there is helpful; from there you'll need to 
write implementations of IStreamServerEndpoint, IListeningPort, and ITransport; 
the breadcrumbs should be laid out well enough that it's pretty clear where 
each of those needs to be though.

Hope that helps, and thanks for actually wanting to use these plugin APIs we 
worked so hard on,

-glyph
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] twistedmatrix.com will be down at some point today for a RAM upgrade

[Itamar Turner-Trauring]

FYI.

-Itamar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted Endpoints and WebSocket / Autobahn

[Tobias Oberstein]

> > 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).


[snip: talk on Endpoints for Serial and Process]

> I hope you'll poke those tickets along through the process.

Thanks for directions! I will have a look into those.


> There's totally a plugin architecture for this, and I'm excited for you to 
> use it :-
> ).
> 
> One quick comment though: would you be OK with using 'autobahn' as your
> identifier rather than 'websocket'?  There are still plans to include basic
> websocket support within Twisted itself and it would be a shame to start
> conflicting on that identifier.

Sure. Can I use:

"autobahn.websocket"

?

Since Autobahn also provides other protocols (WAMP), and ..

==

Thanks for your pointers on the Endpoint plugin architecture. I guess thats 
enough to get me
started - modulo below .. if you could give me 1 more reply with feedback, that 
would be awesome!

In the meantime I did a little more thinking about WebSocket and endpoints.

I can see two approaches - which one is the way forward?


Variant 1)

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)

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? 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"

Is there such thing as a WrappingEndpoint?

==

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?

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.

Thanks a bunch for your thoughts and help!

/Tobias 

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted Endpoints and WebSocket / Autobahn

[Glyph]

On Dec 13, 2013, at 7:09 AM, Tobias Oberstein  
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: 
.

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