[Twisted-Python] Autobahn WebSockets 0.4.3
New release 0.4.3 of Autobahn WebSockets including:
+ Hybi-17 support + TLS (secure WebSocket) + lots of new options + improved docs and tutorials + close behavior coverage for testsuite + many small things I forgot
Special thanks to Peter Thorson for significant code contributions and fruitful discussions! Peter works on a C++/ASIO-based WebSocket client/server framework you may checkout here https://github.com/zaphoyd/websocketpp
Updated Python package is here:
http://pypi.python.org/pypi/autobahn
Updated test suite reports are available under
http://www.tavendo.de/autobahn/testsuite.html
including mobile clients and servers.
Cheers, Tobias
On Mon, Oct 31, 2011 at 8:21 AM, Tobias Oberstein tobias.oberstein@tavendo.de wrote:
New release 0.4.3 of Autobahn WebSockets including:
- Hybi-17 support
- TLS (secure WebSocket)
- lots of new options
- improved docs and tutorials
- close behavior coverage for testsuite
- many small things I forgot
Special thanks to Peter Thorson for significant code contributions and fruitful discussions! Peter works on a C++/ASIO-based WebSocket client/server framework you may checkout here https://github.com/zaphoyd/websocketpp
Updated Python package is here:
http://pypi.python.org/pypi/autobahn
Updated test suite reports are available under
http://www.tavendo.de/autobahn/testsuite.html
including mobile clients and servers.
Hi, how do I run the unit tests for Autobahn? Trial doesn't work, and there don't appear to be any instances of unittest's classes in the tree.
Also, is it possible to run the Autobahn pub-sub and RPC stuff over a different transport than WebSockets, like plain TCP?
~ C.
Hi, how do I run the unit tests for Autobahn? Trial doesn't work, and there don't appear to be any instances of unittest's classes in the tree.
Please see here
http://www.tavendo.de/autobahn/testsuite.html#test_browsers
to get started.
What do you want to test? Own client, own server?
Also, is it possible to run the Autobahn pub-sub and RPC stuff over a different transport than WebSockets, like plain TCP?
In principle, the RPC and PubSub protocol is designed to work over
* reliable, ordered, full-duplex message channel * any serialization format that supports lists and primitive types
Currently, the only binding is WebSocket/JSON.
Raw TCP as a transport .. well, you need some message framing anyway. WebSocket is already quite bare metal.
What are you thinking of? Whats your use case?
~ C.
-- When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson MostAwesomeDude@gmail.com
Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Mon, Oct 31, 2011 at 2:27 PM, Tobias Oberstein tobias.oberstein@tavendo.de wrote:
Hi, how do I run the unit tests for Autobahn? Trial doesn't work, and there don't appear to be any instances of unittest's classes in the tree.
Please see here
http://www.tavendo.de/autobahn/testsuite.html#test_browsers
to get started.
What do you want to test? Own client, own server?
I wanted to test Autobahn's internals. Unit tests, not integration tests. The integration test stuff is pretty cool, too, but I was hoping for tests which verify Autobahn's behavior internally.
Also, is it possible to run the Autobahn pub-sub and RPC stuff over a different transport than WebSockets, like plain TCP?
In principle, the RPC and PubSub protocol is designed to work over
- reliable, ordered, full-duplex message channel
- any serialization format that supports lists and primitive types
Currently, the only binding is WebSocket/JSON.
Raw TCP as a transport .. well, you need some message framing anyway. WebSocket is already quite bare metal.
Well, TCP would fulfill the channel, and something like AMP could be the serializer, I guess. I'm not super-picky. I just wanted to know how flexible the whole thing is.
~ C.
What do you want to test? Own client, own server?
I wanted to test Autobahn's internals. Unit tests, not integration tests. The integration test stuff is pretty cool, too, but I was hoping for tests which verify Autobahn's behavior internally.
You can use Autobahn to test Autobahn of course.
Autobahn's test approach is tailored towards it's domain (communication protocols) and based on the following perspective:
If you have a black box, that behaves to a protocol spec regarding all it's externally visible behavior, you can call that black box conforming to the protocol.
Whether you then have unit tests for stuff that happens within the black box is less relevant, as long as you have covered all the spec with behavioral test cases.
When you only have unit tests for stuff happening inside the box, you still can't say if the box conforms to the spec. It may pass all unit tests and fail when talking to the world.
For protocols, the reason for this is: any unit test by definition misses an essential part: the peer you communicate with.
As an example, instead of writing a unit test that checks whether a UTF-8 decoding function raises upon invalid sequences, execute a fuzzing test case where the fuzzer will actually send the tested implementation invalid UTF-8 and check the externally visible behavior.
On Mon, Oct 31, 2011 at 3:25 PM, Tobias Oberstein tobias.oberstein@tavendo.de wrote:
You can use Autobahn to test Autobahn of course.
Autobahn's test approach is tailored towards it's domain (communication protocols) and based on the following perspective:
If you have a black box, that behaves to a protocol spec regarding all it's externally visible behavior, you can call that black box conforming to the protocol.
Whether you then have unit tests for stuff that happens within the black box is less relevant, as long as you have covered all the spec with behavioral test cases.
When you only have unit tests for stuff happening inside the box, you still can't say if the box conforms to the spec. It may pass all unit tests and fail when talking to the world.
For protocols, the reason for this is: any unit test by definition misses an essential part: the peer you communicate with.
As an example, instead of writing a unit test that checks whether a UTF-8 decoding function raises upon invalid sequences, execute a fuzzing test case where the fuzzer will actually send the tested implementation invalid UTF-8 and check the externally visible behavior.
Okay. This seems reasonable. I really only have two reasons for doing unit tests on top of this, and both are kinda orthogonal: Isolation and specificity. Clearly, I need to do less TDD.
Anyway, I'm running the fuzzer against txWS, and things appear to be working. Thanks for a useful tool!
participants (3)
-
Corbin Simpson -
Iap -
Tobias Oberstein