win32 support

[kanaka]

Add support for win32.

One of the main changes will require using the multiprocessing module rather than os.fork().

[kanaka]

Multiprocessing module docs: http://docs.python.org/library/multiprocessing.html

Shows converting from os.fork to multiprocessing: http://www.ibm.com/developerworks/aix/library/au-multiprocessing/

[kanaka]

Also, note that I would like to maintain os.fork() as a fallback for the python 2.4 case on Linux/UNIX.

[kanaka]

I've converted websockify to use multiprocessing with python 2.6 and greater. I also added python 3.X support: c858711

@ysangkok, can you see if websockify now runs in Windows for you?

[kanaka]

I made the 'resource' module optional (and refactored how optional modules are imported): commit c659bcb.

@ysangkok, please test again. I don't have a Windows system easily accessible at the moment. I'm sure you will run into more issues, so just post them here and we'll work through them iteratively.

[ysangkok]

I tried running, but I can't get it to work. I tried running it with the PDB. See the last 10 statements (I added comments).

Janus@Zeus ~/windesktop
$ /cygdrive/c/Python32/python.exe -m pdb websockify.py 7000 localhost:8000
> c:\users\janus\desktop\websockify.py(12)<module>()
-> '''
(Pdb) until 298
WARNING: no 'numpy' module, HyBi protocol support disabled
WARNING: no 'resource' module, daemonizing support disabled
WebSocket server settings:
  - Listen on :7000
  - Flash security policy server
  - No SSL/TLS support (no cert file)
> c:\users\janus\desktop\websockify.py(298)<module>()
-> server.start_server()
(Pdb) step
--Call--
> c:\users\janus\desktop\websocket.py(682)start_server()
-> def start_server(self):
(Pdb) until
> c:\users\janus\desktop\websocket.py(690)start_server()
-> lsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
(Pdb)
> c:\users\janus\desktop\websocket.py(691)start_server()
-> lsock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
(Pdb)
> c:\users\janus\desktop\websocket.py(692)start_server()
-> lsock.bind((self.listen_host, self.listen_port))
(Pdb)
> c:\users\janus\desktop\websocket.py(693)start_server()
-> lsock.listen(100)
(Pdb)
> c:\users\janus\desktop\websocket.py(695)start_server()
-> if self.daemon:
(Pdb)
> c:\users\janus\desktop\websocket.py(698)start_server()
-> self.started()  # Some things need to happen after daemonizing
(Pdb)
  - proxying from :7000 to localhost:8000

> c:\users\janus\desktop\websocket.py(701)start_server()
-> signal.signal(signal.SIGINT, self.do_SIGINT)
(Pdb)
> c:\users\janus\desktop\websocket.py(702)start_server()
-> if not Process:
(Pdb)
> c:\users\janus\desktop\websocket.py(706)start_server()
-> while True:
(Pdb)
> c:\users\janus\desktop\websocket.py(707)start_server()
-> try:
(Pdb)
> c:\users\janus\desktop\websocket.py(708)start_server()
-> try:
(Pdb)
> c:\users\janus\desktop\websocket.py(709)start_server()
-> self.client = None
(Pdb)
> c:\users\janus\desktop\websocket.py(710)start_server()
-> startsock = None
(Pdb)
> c:\users\janus\desktop\websocket.py(711)start_server()
-> pid = err = 0
(Pdb)
> c:\users\janus\desktop\websocket.py(713)start_server()
-> try:
(Pdb)
> c:\users\janus\desktop\websocket.py(714)start_server()
-> self.poll()
(Pdb)
> c:\users\janus\desktop\websocket.py(716)start_server()
-> ready = select.select([lsock], [], [], 1)[0]; 
(Pdb) 
# NOTE: small pause when executing this statement
> c:\users\janus\desktop\websocket.py(717)start_server()
-> if lsock in ready:
(Pdb)
> c:\users\janus\desktop\websocket.py(720)start_server()
-> continue
(Pdb)
> c:\users\janus\desktop\websocket.py(768)start_server()
-> if startsock: 
(Pdb)
# NOTE: it hangs here until I try and make a WebSocket connection (using wstelnet.html)
> c:\users\janus\desktop\websocket.py(769)start_server()
-> startsock.close()
(Pdb)
# NOTE: seems to hang here indefinitely

[kanaka]

I appreciate the amount of debugging output you have captured. I may have to try and get access to a Windows system to test this since the behavior you are describing is quite odd. I'm not sure pdb is describing everything that is happening because the "if startsock" statement should always be false until the "startsock, address = lsock.accept()" line has been called which doesn't show up in your output. What behavior do you get when you run it without pdb but with the --verbose option?

[ysangkok]

C:\Users\Janus\Documents\My Dropbox\textadventure\static\ws>c:\Python32\python.e
xe websockify --verbose 7000 localhost:8000
WARNING: no 'numpy' module, HyBi protocol support disabled
WARNING: no 'resource' module, daemonizing support disabled
WebSocket server settings:
  - Listen on :7000
  - Flash security policy server
  - No SSL/TLS support (no cert file)
  - proxying from :7000 to localhost:8000

  1: 127.0.0.1: new handler Process
WARNING: no 'numpy' module, HyBi protocol support disabled
WARNING: no 'resource' module, daemonizing support disabled
  1: handler exception: file descriptor cannot be a negative integer (-1)
  1: Traceback (most recent call last):
  File "C:\Users\Janus\Documents\My Dropbox\textadventure\static\ws\websocket.py
", line 662, in top_new_client
    self.client = self.do_handshake(startsock, address)
  File "C:\Users\Janus\Documents\My Dropbox\textadventure\static\ws\websocket.py
", line 490, in do_handshake
    ready = select.select([sock], [], [], 3)[0]
ValueError: file descriptor cannot be a negative integer (-1)

BTW I had to symlink websockify to websockify.py or I would get an ImportError:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "c:\Python32\lib\multiprocessing\forking.py", line 369, in main
    prepare(preparation_data)
  File "c:\Python32\lib\multiprocessing\forking.py", line 486, in prepare
    file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named websockify
  2: Got SIGINT, exiting

[kanaka]

That's strange, apparently the multiprocessing module is doing a new import of the module when spawning the process. Maybe that's normal on Windows, but I wouldn't expect it to throw an exception like that if things are working correctly.

Apparently the socket we get from socket.accept is not valid or is being invalidated by the Process invocation. I've not done much socket programming on Windows so this might be a windows specific issue.

Let's try eliminating the multiprocessing complexities from the mix and see what happens. This change will only be able to handle a single request at a time, but it should show us whether the problem is related to multiprocessing or not:

diff --git a/websocket.py b/websocket.py
index 78e275a..34e1e12 100755
--- a/websocket.py
+++ b/websocket.py
@@ -732,20 +732,20 @@ Sec-WebSocket-Accept: %s\r
                         else:
                             raise

-                    if Process:
-                        self.vmsg('%s: new handler Process' % address[0])
-                        p = Process(target=self.top_new_client,
-                                args=(startsock, address))
-                        p.start()
-                        # child will not return
-                    else:
-                        # python 2.4
-                        self.vmsg('%s: forking handler' % address[0])
-                        pid = os.fork()
-                        if pid == 0:
-                            # child handler process
-                            self.top_new_client(startsock, address)
-                            break  # child process exits
+                    self.top_new_client(startsock, address)
+#                    if Process:
+#                        self.vmsg('%s: new handler Process' % address[0])
+#                        p = Process(target=self.top_new_client,
+#                                args=(startsock, address))
+#                        p.start()
+#                    else:
+#                        # python 2.4
+#                        self.vmsg('%s: forking handler' % address[0])
+#                        pid = os.fork()
+#                        if pid == 0:
+#                            # child handler process
+#                            self.top_new_client(startsock, address)
+#                            break  # child process exits

                     # parent process
                     self.handler_id += 1

BTW, the change above is just calling the top_new_client method directly.

[ysangkok]

Yup, works now: http://i.imgur.com/1r7tt.png :D

Thanks for making it work. I appreciate it a lot.

[kanaka]

@ysangkok, I'll be on vacation for the next 10 days, but I wonder if you might be willing to track down why the handoff of the socket from parent process to child process is breaking. I had a thought that perhaps the startsock.close() in the parent might be the culprit but I don't have an opportunity to test before leaving. After the client is started, the socket should probably only be closed in the client (even on Linux but for some reason Linux tolerates this).

[kanaka]

@ysangkok, have you had a chance to try the multiprocessing support with the startsock.close() line comment out?

[kanaka]

I'm working on refactoring websockify to use python's SocketServer module. This module is designed to work with the ForkingMixin and ThreadingMixin. For Linux I will continue to use the forking model (which should be faster because it will avoid the python GIL) and use threading on Windows (since sharing of listener sockets isn't supported across processes in Windows).

I have basic proxying already working, and I'm working on all the other functionality that websockify supports.

[tdski82]

Forking on windows doesn't work and Python try to Pickling socket (that can't be pickled).

I have the same problem and i resolve with pickling handler instead socket, that work in multiprocess mode (tested on Windows 7 32bit and Python 3.1).

This is my quick fix:

diff a/websocket.py b/websocket.py:

22a23,24
> from multiprocessing.reduction import reduce_handle
> from multiprocessing.reduction import rebuild_handle
732c734
<     def top_new_client(self, startsock, address):
---
>     def top_new_client(self, sockfd, address):
740a743,747
>         fd = rebuild_handle(sockfd)
>         startsock = socket.fromfd(fd, socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_TCP)
>         
>         self.vmsg('%s: new handler Process' % address[0])
>         
786c793
< 
---
>         
802a810
>                     client_sock = None
813c821
< 
---
>                         
816c824,826
<                             startsock, address = lsock.accept()
---
>                             client_sock, address = lsock.accept()
>                             startsock = reduce_handle(client_sock.fileno())
> 
818a829
> 
873,874c884,885
<                 if startsock:
<                     startsock.close()
---
>                 if client_sock:
>                     client_sock.close()

[kanaka]

Fascinating. multiprocessing.reduction is not particularly well publicized. Looking at the code in multiprocessing.reduction, I think the module is designed to automatically update the pickler to handle sockets/connections. The reduce_handle and rebuild_handle functions are not exported so they aren't really designed to be called externally. They are really routines internal to the module that are used for overloading the pickler.

So, I think all that is necessary is the following patch:

diff --git a/websocket.py b/websocket.py
index 37b69c8..d71c46e 100644
--- a/websocket.py
+++ b/websocket.py
@@ -43,6 +43,9 @@ else:
 if sys.hexversion >= 0x2060000:
     # python >= 2.6
     from multiprocessing import Process
+    if sys.platform == 'win32':
+        # make sockets pickable/inheritable
+        import multiprocessing.reduction
     from hashlib import md5, sha1
 else:
     # python < 2.6

It's curious to me that multiprocessing doesn't do that import automatically on Windows.

Anyways, can those listening on this bug please test my simple patch on Windows and see if it does in fact work correctly? If you can, please test multiple simultaneous clients. Hopefully we have both python 2.6 and python 3.0 Windows users listening to this bug.

Thanks

[kanaka]

@tdski82, thanks for the great catch BTW. I was starting to rewrite websockify to use python SocketServer with threading on Windows and forking on Linux. If this multiprocessing.reduction idea you found works, that will be much cleaner (and should be faster on Windows) and save me a bunch of work. So thanks!

[kanaka]

Also for testers, please test this with wss/SSL connections.

[tdski82]

It's enough only the import patch that you wrote, BTW i think that MultiThreading is best choise for the future.

I read that the fix for handler pickling has been implemented from Python 3.1.

This morning i try it behind noVNC and with 4 concurrent and active connection and work fine (sometime i see an Exception in output but i don't have dump of this error)

Python version tested with new pickling fix (clean Python installation):

• 2.6.7 - NOT OK

Exception on socket pickling

• 2.7 - NOT OK

Exception on socket pickling

• 3.01 - NOT OK

1: handler exception: file descriptor cannot be a negative integer (-1)
1: Traceback (most recent call last):
File "c:\novnc\utils\websocket.py", line 746, in top_new_client
self.client = self.do_handshake(startsock, address)
File "c:\novnc\utils\websocket.py", line 568, in do_handshake
ready = select.select([sock], [], [], 3)[0]
ValueError: file descriptor cannot be a negative integer (-1)

• 3.1.2 - OK
• 3.2.2 - OK

Fix for Python 3.01 or grater without socket pickling (less version doesn't have fromfd method on socket on Windows environment):

# pass descriptor to top_new_client (without socket pickling)
self.top_new_client(startsock.fileno(), address)

# change parameter on method
def top_new_client(self, startsockfd, address):

# recreate socket by passed descriptor ( in top_new_client(....) )
startsock = socket.fromfd(startsockfd, socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_TCP)

[jmcintyre]

I'm doing some testing to see if I can get websockify to replace another product we are using on windows, and after I did the symlink websockify.py to websockify trick, it looked like everything was going to run well. The browser is making the connection to the socket, and sending its data, however, the message never gets to the intended server. Here are the messages I get in verbose mode:

WARNING: no 'resource' module, daemonizing is slower or disabled
  3: Warning: client does not report 'base64' protocol support
  3: 127.0.0.1: Plain non-SSL (ws://) WebSocket connection
  3: 127.0.0.1: Version hixie-76, base64: 'True'
  3: 127.0.0.1: Path: '/menu?.kl=Y'
  3: connecting to: localhost:8988

Traffic Legend:
    }  - Client receive
    }. - Client receive partial
    {  - Target receive

    >  - Target send
    >. - Target send partial
    <  - Client send
    <. - Client send partial

And that is all that I get. The warning that there is no base64 followed by base64: 'True' seems odd, but I don't know that t is actually an issue. I am not using the js file that is shipped with websockify at this time, I'm testing with our existing websocket code.

[kanaka]

Currently, if the client doesn't report that it supports raw binary (via the 'binary' in the websocket sub-protocol) then websockify assumes that it must base64 encode/decode any traffic to/from the browser. It's warning you that the client didn't report anything in the sub-protocol but that it is going ahead and using base64 encoding anyway.

I might suggest that you try running the echo test. Run this:
./tests/echo.py 8080

Then browse to localhost:8080/tests/echo.html?host=localhost&port=8080 and hit start. Make sure that works (you should see messages sent and received in the text box). Once that works, go from there.

[jmcintyre]

I had to create another symbolic link from websockify/test/include to websockify/include and then the echo test worked.

I've modified my script to send/receive base64 encoded data, but I'm still not seeing the packet get to the final server. Is there a better logging method than verbose where I could see that data that is passed across?

[jmcintyre]

I take it back. The message is getting through, and has the correct number of bytes, but they are all 0.

[kanaka]

Try this for really verbose logging:

diff --git a/websocket.py b/websocket.py
index 2b3bacc..3b6808c 100644
--- a/websocket.py
+++ b/websocket.py
@@ -441,6 +445,7 @@ Sec-WebSocket-Accept: %s\r
                             repr("{%s{" % tdelta
                                 + encbuf[lenhead:-lentail]))

+                print("Sent buf: %s, encbuf: %s" % (repr(buf), repr(encbuf)))
                 self.send_parts.append(encbuf)

         while self.send_parts:
@@ -515,6 +520,7 @@ Sec-WebSocket-Accept: %s\r
                 frame = self.decode_hixie(buf)

             self.traffic("}")
+            print("Received buf: %s, frame: %s" % (repr(buf), frame))

             if self.rec:
                 start = frame['hlen']

With the echo test you would see something like this (if using a browser using HyBi-76 such as Chrome 13):

Received buf: '\x00TWVzc2FnZSAjMQ==\xff', frame: {'hlen': 1, 'length': 16, 'payload': 'Message #1', 'left': 0}
Sent buf: 'Message #1', encbuf: '\x00TWVzc2FnZSAjMQ==\xff'
Received buf: '\x00TWVzc2FnZSAjMg==\xff', frame: {'hlen': 1, 'length': 16, 'payload': 'Message #2', 'left': 0}
Sent buf: 'Message #2', encbuf: '\x00TWVzc2FnZSAjMg==\xff'

If you still are seeing a problem after adding that, post the debug you get here and I'll take a look.

[jmcintyre]

Thanks for the help code. I pretty quickly realized I was being dumb and missed the part in echo where it packed the string into an integer array before running the base64 encode.

So, to summarize, I was able to get websockify running on Windows by using Python 3.2 with a symlink from websockify.py to websockify. Also, the tests required an additional symlink from websockify/test/include to websockify/include.

[hugoslv]

Hi,

I've tried to put echo.py to work but I'm getting the error:

WARNING: no 'resource' module, daemonizing is slower or disabled
Traceback (most recent call last):
File "", line 1, in
File "C:\Python27\lib\multiprocessing\forking.py", line 374, in main
self = load(from_parent)
File "C:\Python27\lib\pickle.py", line 1378, in load
return Unpickler(file).load()
File "C:\Python27\lib\pickle.py", line 858, in load
dispatchkey
File "C:\Python27\lib\pickle.py", line 1133, in load_reduce
value = func(*args)
File "C:\Python27\lib\multiprocessing\reduction.py", line 193, in rebuild_sock
et
sock = fromfd(fd, family, type, proto)
File "C:\Python27\lib\multiprocessing\reduction.py", line 182, in fromfd
s = socket.fromfd(fd, family, type_, proto)
AttributeError: 'module' object has no attribute 'fromfd'

Do you have any thoughts on what might be going on?

[kanaka]

I think @snorkeyg has gotten websockify to work with python 2.7 on Windows. I'll ask him to weigh in.

In the meantime, if you scroll back a few comments to the test results from @tdski82, it indicates that python 3.1 and 3.2 should work fine and that python 2.X and python 3.0 do not work due to the lack of some Windows related fixes in the multiprocessing module.

[snorkeyg]

Hi @hugoslv. I have websockify working well on Windows. I have applied @kanaka's patch as per comment by @kanaka on May 20, 2011 in this thread to fix the error you are having above. I'm not actually sure if windows has a patch tool and I'm more familiar with this kind of thing in Unix so I actually applied the patch in linux, copied it all to windows box and it ran sweet.

If you want I can just send you patched copy of this file?

I had almost forgotten about this issue, I have been meaning to get back to this and see if I can have crack at proper multiprocessing on Windows.

[snorkeyg]

Also to clarify I was using Python 2.7. Not sure if Python version makes to much difference once the patch is applied but, that's a possibility.

[hugoslv]

Thank's Guys,

I'll try the suggested fix and get back to you in case the problems persist.

Best regards,
Hugo Silva

On Nov 7, 2011, at 11:30 PM, Chris Gordon wrote:

Hi @hugoslv. I have websockify working well on Windows. I have applied @kanaka's patch as per comment by @kanaka on May 20, 2011 in this thread to fix the error you are having above. I'm not actually sure if windows has a patch tool and I'm more familiar with this kind of thing in Unix so I actually applied the patch in linux, copied it all to windows box and it ran sweet.

If you want I can just send you patched copy of this file?

I had almost forgotten about this issue, I have been meaning to get back to this and see if I can have crack at proper multiprocessing on Windows.

---

Reply to this email directly or view it on GitHub:
#2 (comment)

[kanaka]

@hugoslv, just to be clear, the python 2.7 "fix" disables multi-processing in websockify. What this means is that you lose the ability to connect more than one client to the server through the same websockify instance. If you run websockify with python 3.1 or 3.2 then it should work on windows AND have multiprocessing support.

[kanaka]

Okay, that's probably sufficient. I'll catch modifications to websockify.py in any pull requests and have the devs using Windows re-submit pulls using websockify instead.

[eph214]

hi guys,

i'm still having issues.. I created a shortcut in the same folder named websockify.py (checked properties, it's named right)

still get same issue as above from this:
C:\noVNC\utils>c:\python32\python.exe websockify :8080 127.0.0.1:5900
WARNING: no 'resource' module, daemonizing is slower or disabled
WebSocket server settings:

• Listen on :8080
• Flash security policy server
• No SSL/TLS support (no cert file)
• proxying from :8080 to 127.0.0.1:5900

Traceback (most recent call last):
File "", line 1, in
File "c:\python32\lib\multiprocessing\forking.py", line 369, in main
prepare(preparation_data)
File "c:\python32\lib\multiprocessing\forking.py", line 486, in prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named websockify

Next I tried just removing the shortcut and copying the websockify file directly to websockify.py file. Then i get a different error when i attempt to connect:
C:\noVNC\utils>c:\python32\python.exe c:\noVNC\utils\websockify :8080 127.0.0.1:
5900
WARNING: no 'resource' module, daemonizing is slower or disabled
WebSocket server settings:

• Listen on :8080
• Flash security policy server
• No SSL/TLS support (no cert file)
• proxying from :8080 to 127.0.0.1:5900

WARNING: no 'resource' module, daemonizing is slower or disabled
1: 192.168.248.1: ignoring socket not ready

it allows me to connect (from raw telnet to port 8080 on a different host) and then exits.
very weird.

[eph214]

also to get the above (very short) connection, i also had to remove the call to python in the websockify.py file (#!/usr/bin/env python )

[kanaka]

"Ignoring socket not ready" means that when the server went to process the handshake, there was no data on the socket channel.

You can try increasing the timeout from 3 to 100 (ms) in do_handshake:

ready = select.select([sock], [], [], 100)[0]

There really shouldn't be any delay I don't think, but the way multiprocessing works on Windows could be introducing some delay somehow.

[eph214]

with that change to increasing the timeout, i get this response now :

10: handler exception: file descriptor cannot be a negative integer (-1)

when i telnet to localhost on 8080 while running
C:\noVNC\utils>c:\python32\python.exe websockify :8080 127.0.0.1:5900 in a different cmd window

and it closes the connection again after a few seconds.

[eph214]

If it's working for someone else, can you please post the exact version of novnc and the exact version of python you are running? I'm testing with

kanaka-noVNC-v0.1-64-g2fa565b
and
python-3.2.2 (windows installer)

i'm running windows xp sp3 in a virtualbox vm.

[vicky555]

Hey eph214, i guess i faced the same problem before, i am using python 2.7 with patched version of websockify as i described above. Its working fine for me.

[agnivade]

Hi @vicky555 , I am also using Windows 7 with python 2.7. Trying very hard to get this work. I read the thread about differences between python 2.7 and 3.1, I incorporated the changes for the import multiprocessing.reduction and also the Process call in start_server() function. But still I am getting the same error

PS E:\Misc projects\noVNC> python .\utils\websockify.py --web ./ 8787 localhost:5901 --cert .\utils\self.pem
WARNING: no 'numpy' module, HyBi protocol is slower or disabled
WARNING: no 'resource' module, daemonizing is slower or disabled
WebSocket server settings:

• Listen on :8787
• Flash security policy server
• Web server. Web root: E:\Misc projects\noVNC
• SSL/TLS support
• proxying from :8787 to localhost:5901

WARNING: no 'numpy' module, HyBi protocol is slower or disabled
WARNING: no 'resource' module, daemonizing is slower or disabled
Traceback (most recent call last):
File "", line 1, in
File "D:\Python27\lib\multiprocessing\forking.py", line 374, in main
self = load(from_parent)
File "D:\Python27\lib\pickle.py", line 1378, in load
return Unpickler(file).load()
File "D:\Python27\lib\pickle.py", line 858, in load
dispatchkey
File "D:\Python27\lib\pickle.py", line 1133, in load_reduce
value = func(*args)
File "D:\Python27\lib\multiprocessing\reduction.py", line 193, in rebuild_socket
sock = fromfd(fd, family, type, proto)
File "D:\Python27\lib\multiprocessing\reduction.py", line 182, in fromfd
s = socket.fromfd(fd, family, type_, proto)
AttributeError: 'module' object has no attribute 'fromfd'

Actually I am too confused as to exactly what changes to do in my files to get it running for python 2.7. Can you help me out in this regard ? It would be very helpful if you could show me the modified websocket.py and websockify.py.

[vicky555]

@agnivade i am using following files which you have mentioned..
please download both files from
http://www.fileswap.com/dl/EYj3rk4zof/
http://www.fileswap.com/dl/pyr0BppSJA/

[agnivade]

@vicky555 many thanks. Its working now.

[vicky555]

@agnivade you are welcome.. :)

[pushakargaikwad]

@vicky555 can u please share those files again. the links seem to be broken now. thanks in advance :)

[vicky555]

@pushakargaikwad please download files from following ur
http://s000.tinyupload.com/?file_id=91614758356692933726
http://s000.tinyupload.com/?file_id=02238768050340581102
Thanks

[drussilla]

To fix
"
Traceback (most recent call last):
File "", line 1, in
File "c:\python32\lib\multiprocessing\forking.py", line 369, in main
prepare(preparation_data)
File "c:\python32\lib\multiprocessing\forking.py", line 486, in prepare
file, path_name, etc = imp.find_module(main_name, dirs)
ImportError: No module named websockify
"
Just copy websockify to websockify.py (with replacing). Detailed instruction you can look here: http://druss.pp.ua/2013/10/run-novnc-websockify-on-windows-server-disconnected-code-1006-fixed/

[groupboard]

Has anyone managed to get it working on Windows? I've tried on Vista and Win7 with python 3.4 and portable python, but I always get this error:

ImportError: No module named 'websocket'.

Any suggestions? It works fine on linux.

[vedmack]

Same problem here, after compiling websockify as windows executable I can't manage to use it without getting errors (I'm not even sure that the compiled (using portable python 2.7 version will support multiple client connection at a time)) , I also posted a Q' on stackoverflow , Help will be appreciated...

[groupboard]

The solution is to use the Node.js version on Windows, instead of the php version. It works like a charm, out of the box.

[vedmack]

Did anyone managed to run websockify (python) on windows with multiprocessing support (with the ability to connect more than one client to the server through the same websockify instance), if so, please tell me how, Thanks! (can't use Node.js version)

[vicky555]

@vedmack follow this issue.. your problem will be solved

#3

[kobemajian]

C:\Users\majian-xy>python E:\noVNC\utils\websockify 7777 10.18.27.57:5900

WARNING: no 'numpy' module, HyBi protocol will be slower
WARNING: no 'resource' module, daemonizing is disabled
WebSocket server settings:

• Listen on :7777
• Flash security policy server
• No SSL/TLS support (no cert file)
• proxying from :7777 to 10.18.27.57:5900
  Traceback (most recent call last):
  File "E:\noVNC\utils\websocket.py", line 999, in start_server
  p.start()
  File "D:\Python32\lib\multiprocessing\process.py", line 132, in start
  self._popen = Popen(self)
  File "D:\Python32\lib\multiprocessing\forking.py", line 272, in init
  dump(process_obj, to_child, HIGHEST_PROTOCOL)
  File "D:\Python32\lib\multiprocessing\forking.py", line 194, in dump
  ForkingPickler(file, protocol).dump(obj)
  File "D:\Python32\lib\pickle.py", line 237, in dump
  self.save(obj)
  File "D:\Python32\lib\pickle.py", line 344, in save
  self.save_reduce(obj=obj, *rv)
  File "D:\Python32\lib\pickle.py", line 432, in save_reduce
  save(state)
  File "D:\Python32\lib\pickle.py", line 299, in save
  f(self, obj) # Call unbound method with explicit self
  File "D:\Python32\lib\pickle.py", line 627, in save_dict
  self._batch_setitems(obj.items())
  File "D:\Python32\lib\pickle.py", line 660, in _batch_setitems
  save(v)
  File "D:\Python32\lib\pickle.py", line 299, in save
  f(self, obj) # Call unbound method with explicit self
  File "D:\Python32\lib\multiprocessing\forking.py", line 69, in dispatcher
  self.save_reduce(obj=obj, *rv)
  File "D:\Python32\lib\pickle.py", line 414, in save_reduce
  save(args)
  File "D:\Python32\lib\pickle.py", line 299, in save
  f(self, obj) # Call unbound method with explicit self
  File "D:\Python32\lib\pickle.py", line 533, in save_tuple
  save(element)
  File "D:\Python32\lib\pickle.py", line 344, in save
  self.save_reduce(obj=obj, *rv)
  File "D:\Python32\lib\pickle.py", line 432, in save_reduce
  save(state)
  File "D:\Python32\lib\pickle.py", line 299, in save
  f(self, obj) # Call unbound method with explicit self
  File "D:\Python32\lib\pickle.py", line 627, in save_dict
  self._batch_setitems(obj.items())
  File "D:\Python32\lib\pickle.py", line 660, in _batch_setitems
  save(v)
  File "D:\Python32\lib\pickle.py", line 344, in save
  self.save_reduce(obj=obj, *rv)
  File "D:\Python32\lib\pickle.py", line 432, in save_reduce
  save(state)
  File "D:\Python32\lib\pickle.py", line 299, in save
  f(self, obj) # Call unbound method with explicit self
  File "D:\Python32\lib\pickle.py", line 627, in save_dict
  self._batch_setitems(obj.items())
  File "D:\Python32\lib\pickle.py", line 660, in _batch_setitems
  save(v)
  File "D:\Python32\lib\pickle.py", line 344, in save
  self.save_reduce(obj=obj, *rv)
  File "D:\Python32\lib\pickle.py", line 432, in save_reduce
  save(state)
  File "D:\Python32\lib\pickle.py", line 299, in save
  f(self, obj) # Call unbound method with explicit self
  File "D:\Python32\lib\pickle.py", line 627, in save_dict
  self._batch_setitems(obj.items())
  File "D:\Python32\lib\pickle.py", line 660, in _batch_setitems
  save(v)
  File "D:\Python32\lib\pickle.py", line 299, in save
  f(self, obj) # Call unbound method with explicit self
  File "D:\Python32\lib\pickle.py", line 579, in save_list
  self._batch_appends(obj)
  File "D:\Python32\lib\pickle.py", line 614, in _batch_appends
  save(tmp[0])
  File "D:\Python32\lib\pickle.py", line 344, in save
  self.save_reduce(obj=obj, *rv)
  File "D:\Python32\lib\pickle.py", line 432, in save_reduce
  save(state)
  File "D:\Python32\lib\pickle.py", line 299, in save
  f(self, obj) # Call unbound method with explicit self
  File "D:\Python32\lib\pickle.py", line 627, in save_dict
  self._batch_setitems(obj.items())
  File "D:\Python32\lib\pickle.py", line 660, in _batch_setitems
  save(v)
  File "D:\Python32\lib\pickle.py", line 319, in save
  rv = reduce(self.proto)
  TypeError: cannot serialize '_io.TextIOWrapper' object

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "E:\noVNC\utils\websockify", line 471, in
websockify_init()
File "E:\noVNC\utils\websockify", line 419, in websockify_init
server.start_server()
File "E:\noVNC\utils\websocket.py", line 1017, in start_server
self.msg("handler exception: %s", str(exc))
UnboundLocalError: local variable 'exc' referenced before assignment

C:\Users\majian-xy>WARNING: no 'numpy' module, HyBi protocol will be slower
WARNING: no 'resource' module, daemonizing is disabled
Traceback (most recent call last):
File "", line 1, in
File "D:\Python32\lib\multiprocessing\forking.py", line 375, in main
self = load(from_parent)
EOFError

[alexchandel]

Python 2 was end-of-lifed on January 1. Python 3.8 has complete Windows support for non-blocking TCP & UDP asyncio. Convert websockify to use asyncio and it'll work natively on Windows.

[CendioOssman]

Windows support was fixed back in #388 so this should have been closed then.