Re: [Twisted-Python] stop/start client connections with loseConnection in ReconnectingClientFactory

Am 02.04.19 um 09:03 schrieb Chris Withers:
On 02/04/2019 07:56, Tobias Oberstein wrote:
Would be good to get that converted...
yeah, agreed.
unlikely to happen though (lack of time) unless someone steps up with a PR
Okay, but then don't be surprised when people get tripped up by it...
well, I never claimed to be surprised. I was only triggered by the reference to our _docs_ as we've put quite some work improving on that. but honestly, lets not further drum that line;) it leads nowhere. I am with you: there is room for improvements. if you have a PR, please think about contributing! we'll be working with you / merging ..
What's the simplest way to connect a ClientService to a websocket url (ie: ws://host/endpoint or wss://host/endpoint)
you might adapt / start from this (again WAMP, but just a matter of using websocket rather than wamp factories/protocols):
https://github.com/crossbario/autobahn-python/blob/master/examples/twisted/w...
Any way to get rid of the ugly duplication between the url in line 69 and the endpoint on line 72?
I seem to remember that ends up happening with or without ClientService.
I am aware, but no, it's designed like this, because WebSocket requires a HTTP URL (with potentially path components, query parameters etc) in the opening handshake while the _transport_ does not necessarily have that. Autobahn allows you to run WebSocket over basically everything that is a bidirectional byte pipe: TCP of course, but also Unix domain socket, pipes, Tor onion services (via https://github.com/meejah/txtorcon) and even serial ports! Cheers, /Tobias
Chris

On 02/04/2019 08:25, Tobias Oberstein wrote:
https://github.com/crossbario/autobahn-python/blob/master/examples/twisted/w...
Any way to get rid of the ugly duplication between the url in line 69 and the endpoint on line 72?
I seem to remember that ends up happening with or without ClientService.
I am aware, but no, it's designed like this, because WebSocket requires a HTTP URL (with potentially path components, query parameters etc) in the opening handshake while the _transport_ does not necessarily have that.
Autobahn allows you to run WebSocket over basically everything that is a bidirectional byte pipe: TCP of course, but also Unix domain socket, pipes, Tor onion services (via https://github.com/meejah/txtorcon) and even serial ports!
Right, but correct me if I'm wrong, my understanding is that URL stands for Univeral Resource Locator and URLs can encode all of the things you describe. They certainly contain the host and port, so shouldn't there be a graceful way to specify a URL once and have everything that needs that info or a subset of it get it from there? (This isn't necessarily aimed at AutoBahn, seems to be something common in Twisted...) Chris

Am 02.04.19 um 09:50 schrieb Chris Withers:
On 02/04/2019 08:25, Tobias Oberstein wrote:
https://github.com/crossbario/autobahn-python/blob/master/examples/twisted/w...
Any way to get rid of the ugly duplication between the url in line 69 and the endpoint on line 72?
I seem to remember that ends up happening with or without ClientService.
I am aware, but no, it's designed like this, because WebSocket requires a HTTP URL (with potentially path components, query parameters etc) in the opening handshake while the _transport_ does not necessarily have that.
Autobahn allows you to run WebSocket over basically everything that is a bidirectional byte pipe: TCP of course, but also Unix domain socket, pipes, Tor onion services (via https://github.com/meejah/txtorcon) and even serial ports!
Right, but correct me if I'm wrong, my understanding is that URL stands for Univeral Resource Locator and URLs can encode all of the things you
WebSocket needs a _HTTP_ URL an URL from the HTTP scheme cannot encode eg a Unix domain socket path or a serial port one could certainly come with with other/different non-HTTP URL schemes .. and in some way, Autobahn WAMP machinery has sth in that direction: eg WAMP can be run not only over WebSocket, but also RawSocket, which is a WAMP-specific transport (above byte-level, at the framing level), that is simpler than WebSocket, and for that we using (non-standard) URLs like rs://<host:port> rss://<host:port> fwiw, WAMP is a protocol with a clear-cut, rigorous and decoupled layering: - bidirectional reliable byte level transport (tcp, uds, pipes, ..) - message framing (websocket, rawsocket, ..) - serialization (json, cbor, flatbuffers, ..) and Autobahn and Crossbar.io support _every_ combination of those layers (dozens) to run WAMP
describe. They certainly contain the host and port, so shouldn't there be a graceful way to specify a URL once and have everything that needs that info or a subset of it get it from there?
a (fully qualified) HTTP URL of course encodes a host and port, but that only covers transports that have those notions
(This isn't necessarily aimed at AutoBahn, seems to be something common in Twisted...)
things look only "simple" when leaving out details;) anyways: this is now OT to the original issue I would think ..
Chris

On 02/04/2019 09:07, Tobias Oberstein wrote:
Right, but correct me if I'm wrong, my understanding is that URL stands for Univeral Resource Locator and URLs can encode all of the things you
WebSocket needs a _HTTP_ URL
Not sure I follow, I specify ws:// and things work. What am I missing? (I know the initial protocol is http and that's "upgraded" into websocket, but the url is still ws:// or wss://, right?)
fwiw, WAMP is a protocol with a clear-cut, rigorous and decoupled layering:
Do browsers speak WAMP? Do firewalls get upset with it?
describe. They certainly contain the host and port, so shouldn't there be a graceful way to specify a URL once and have everything that needs that info or a subset of it get it from there?
a (fully qualified) HTTP URL of course encodes a host and port, but that only covers transports that have those notions
Not sure what you mean by fully qualified?
(This isn't necessarily aimed at AutoBahn, seems to be something common in Twisted...)
things look only "simple" when leaving out details;)
There's never a reasonable excuse for duplicating the same information within a few lines of code. Chris

Chris Withers <chris@withers.org> writes:
Not sure I follow, I specify ws:// and things work. What am I missing? (I know the initial protocol is http and that's "upgraded" into websocket, but the url is still ws:// or wss://, right?)
What Tobias is getting at, I think, is that your URL could be wss://example.com/ws but the endpoint could be a unix-socket at /var/run/foo Now, that said, some of the APIs do allow you to shortcut this in the case when your endpoint will be the same as the host in the URI. Compare these two "Component" examples; the first uses the "long form" way to specify the URL + transport and the second is just a string: https://github.com/crossbario/autobahn-python/blob/master/examples/twisted/w... https://github.com/crossbario/autobahn-python/blob/master/examples/twisted/w...
fwiw, WAMP is a protocol with a clear-cut, rigorous and decoupled layering:
Do browsers speak WAMP?
Yes. See Autobahn-JS
Do firewalls get upset with it?
No. WAMP connections are usually "outbound" style connections to the router, so most firewall configurations will be fine with this. -- meejah

Am 10.04.19 um 19:46 schrieb meejah:
Chris Withers <chris@withers.org> writes:
Not sure I follow, I specify ws:// and things work. What am I missing? (I know the initial protocol is http and that's "upgraded" into websocket, but the url is still ws:// or wss://, right?)
What Tobias is getting at, I think, is that your URL could be wss://example.com/ws but the endpoint could be a unix-socket at /var/run/foo
yeah, exactly. thx for helping out;)
fwiw, WAMP is a protocol with a clear-cut, rigorous and decoupled layering:
Do browsers speak WAMP?
Yes. See Autobahn-JS
Do firewalls get upset with it?
No.
WAMP connections are usually "outbound" style connections to the router, so most firewall configurations will be fine with this.
yes! let me add some more details (which are irrelevant in most common cases) - "usually": WAMP _can_ run _also_ over connections where the WAMP level peer role assignment (client vs router) is fully independent of the transport level role (client vs server) assignment as dictated from the direction of connection establishment. eg when runnin WAMP over pipes on Twisted, the connection establishment / transport roles are reversed - firewalls: np as long as _outbound_ TLS on 443 is allowed (HTTPS). no open ports whatsoever are required, and WAMP still allows you to to RPCs _from_ the cloud _to_ the thing sitting inside / behind the firewall. you can even do RPCs between 2 browser tabs (https://crossbario.com/blog/Free-Your-Code-Backends-in-the-Browser/) - MITM https proxies: those TLS unwrapping intermediaries might break websocket - if they are not websocket aware or sidestepping via admin config of the MITM box. anything over websocket is affected then (not only WAMP). TLS v1.3 will make those privacy breaking intermediaries sad anyways - which is a GOOD THING!! luckily, the IETF dismissed the last minute push from the banking corps in particular to compromise TLS v1.3. there are a couple of threads on the IETF WG which really are fun to read;)
participants (3)
-
Chris Withers
-
meejah
-
Tobias Oberstein