Integrating websocket.py into existing service #71
Comments
|
(pasting in email reply from kanaka)
That's a really good question. There are several factors that complicate the situation:
Anyways, the biggest issue really is that websockify needs direct access to the raw socket after the handshake. This might be a lot easier to do if you drop Flash policy and Hixie. It's been a while since I looked into the structure of HTTP classes to see if there is an easy way to access the underlying socket. For example, I recall that rfile and wfile and streams over the socket and those are not sufficient. One possibility would be for the desired handler to be passed in as an argument and then monkey patched to do what is needed and capture the raw socket. Certainly, if you came up with a patch to make websockify more cleanly integrate with existing python web serving classes, I would be happy to consider merging it into the upstream. In particular if there is a way to detect a Flash policy request (e.g. by catching an exception or something like that) then that would be ideal and allow Flash policy requests to be handled.
Yep! There are a couple other places that use print() to that should be changed also. Send me a patch :-)
In general, I strongly agree. I don't have time to work on this directly except to give advice, review patches, and merge in good changes. It's no longer part of my day job and I just started part-time school, so as much as I would like, I don't have much opportunity to improve websockify or noVNC. The main open source project that I work on when I do have a few moments of free time is clojurescript-in-clojurescript (https://github.com/kanaka/clojurescript [github.com]). BTW, websockify has quite a bit of functionality so there is a fair amount of baggage to pull forward with major refactoring. However, the base functionality of websockify is actually quite simple: accept WebSocket connections, open a raw TCP socket, and then bridge between the two by framing/unframing to WebSocket. I am willing to host two python implementations for a while in the upstream repo and gradually add the current functionality to the new implementation as I (or others) have time. Just thought I would throw that out there to try and entice you ;-) |
Yes, in our case, we do not need support for Flash policy request handling.
I see. We do not need Hixie, but a basic web server.
Ok.
Yes, our requirements are "Python 2.4 or newer 2.X version", ie we do not support Python 3 yet.
The documentation for the SocketServer module says: "For stream services, self.request is a socket object". Limiting ourselves to stream services should be a reasonable limitation. However, one problem is that BaseHTTPRequestServer et al assumes that rfile is available, since it wants to use .readline() etc. Another problem is that rfile is buffered by default, so if we switch to using the raw socket later in, we might have stale data in the rfile buffer.
:-) I'll see what I can come up with. |
Rename self.client to self.request, since this is what standard SocketServer request handlers are using.
Move around functions and methods, so that connection-related and server-related stuff are close together. This patch just moves things around - it does not change anything at all. This can be verified with: git diff websocket.py | grep ^- | cut -c 2- | sort > removed git diff websocket.py | grep ^+ | cut -c 2- | sort > added diff -u removed added
* Move traffic_legend. * Since websocket.WebSocketServer.socket is static, don't call it with self.socket.
refactoring. Basically, we are dividing WebSocketServer into two
classes: One request handler following the SocketServer Requesthandler
API, and one optional server engine. The standard Python SocketServer
engine can also be used.
websocketproxy.py has been updated to match the API change. I've also
added a new option --libserver in order to use the Python built in
server instead.
I've done a lot of testing with the new code. This includes: verbose,
daemon, run-once, timeout, idle-timeout, ssl, web, libserver. I've
tested both Python 2 and 3. I've also tested websocket.py in another
external service.
Code details follows:
* The new request handler class is called WebSocketRequestHandler,
inheriting SimpleHTTPRequestHandler.
* The service engine is called WebSocketServer, just like before.
* do_websocket_handshake: Using send_header() etc, instead of manually
sending HTTP response.
* A new method called handle_websocket() upgrades the connection to
WebSocket, if requested. Otherwise, it returns False. A typical
application use is:
def do_GET(self):
if not self.handle_websocket():
# handle normal requests
* new_client has been renamed to new_websocket_client, in order to
have a better name in the SocketServer/HTTPServer request handler
hierarchy.
* Note that in the request handler, configuration variables must be
provided by the "server" object, ie self.server.target_host.
astrand/websockify:
Prepare for fixing #71:
Move around functions and methods, so that connection-related and
server-related stuff are close together.
This patch just moves things around - it does not change anything at
all. This can be verified with:
git diff websocket.py | grep ^- | cut -c 2- | sort > removed
git diff websocket.py | grep ^+ | cut -c 2- | sort > added
diff -u removed added
|
is there an example script showing how to use this? I for example, am using Flask. Based on what I gleaned last year from this repo and maybe others, I came up with a solution that is working albeit slowly, using two threads once a |
I'm struggling with how to integrate websocket.py with an existing Python service. I'm hoping you can provide some advice. Here's the case:
We have an existing web service written in Python, based on Cheetah templates. The engine is the Python stock SocketServer and BaseHTTPServer. A separate binary/process deals with TLS encryption and communicates with the Python process over a UNIX socket. The service is created with:
class ForkingHTTPServer(SocketServer.ForkingMixIn, SocketServer.UnixStreamServer):
The handler derives from BaseHTTPRequestHandler. All in all, pretty standard and straight forward.
Now, the question is how websocket.py could be used in such context. I've noticed that websocket.py does not use any stock service engine, but rather creates sockets, forks etc manually. In order to provide websocket.WebSocketServer with existing file descriptors etc, we would need to override WebSocketServer.start_server(), but is this really safe and intended?
Another problem is that init prints stuff to standard out. Shouldn't it use msg() instead?
In general, websocket.py is very nice, but I think it would be even better if there was a clear separation between the Websocket "protocol" and service stuff such as sockets, TLS, VNC recording etc. Thoughts?
The text was updated successfully, but these errors were encountered: