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: https://github.com/kanaka/websockify/commit/c8587115bc7168e860d7294f9725200272fd8c73

@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: https://github.com/kanaka/websockify/issues/2#issuecomment-2661591

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

[hugoslv]

@joel, thank's

On Nov 8, 2011, at 12:26 AM, Joel Martin wrote:

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

---

Reply to this email directly or view it on GitHub: https://github.com/kanaka/websockify/issues/2#issuecomment-2662143

[vicky555]

I am facing problems during novnc configuration. wherever i tried to access using browser it shows following error . An invalid or illegal string was specified [Break On This Error] websocket = new WebSocket(uri, 'base64');

Kindly help me....Thanks in advance

[kanaka]

@vicky555, you added this to the issue related to running websockify on Windows. Is that what you intended? Is this only a problem when you run websockify on Windows? What browser are you running?

[vicky555]

yes i configured novnc in linux successfuly. but in windows websockify creating problem..i am using Firefox and chrome. i used websockify with pyton 2.7, can you brief me that how to compile this and access in browser??? it will be great help for me..Thanks for your quick response

[vicky555]

Whenever i access the url http://192.168.3.51:9000/wstelnet.html it shows following error in browser...

The connection to ws://192.168.3.51:7000/ was interrupted while the page was loading. websocket = new WebSocket(uri, 'base64');

and error in command line

C:\Documents and Settings\waqasr>cd ../../

C:>cd kanaka-noVNC-02a7dd2

C:\kanaka-noVNC-02a7dd2>cd utils

C:\kanaka-noVNC-02a7dd2\utils>C:\Python27\python.exe websockify --verbose 7000 localhost:8000 WARNING: no 'resource' module, daemonizing decode may be slower WebSocket server settings:

• Listen on :7000
• Flash security policy server
• No SSL/TLS support (no cert file)

• proxying from :7000 to localhost:8000

  1: 192.168.3.51: Plain non-SSL (ws://) WebSocket connection 1: 192.168.3.51: Version hybi-08, base64: 'True' 1: connecting to: localhost:8000 1: handler exception: [Errno 10061] No connection could be made because the target machine actively refused it 1: Traceback (most recent call last): File "C:\kanaka-noVNC-02a7dd2\utils\websocket.py", line 755, in top_new_client self.new_client() File "websockify", line 154, in new_client tsock.connect((self.target_host, self.target_port)) File "C:\Python27\Lib\socket.py", line 224, in meth return getattr(self._sock,name)(*args) error: [Errno 10061] No connection could be made because the target machine actively refused it

Kindly help me....Waiting for your response thanks

[vicky555]

How can i access windows desktop using NoVNC?..like i can access Linux desktop using HTML5 compatible browser... I am using HTML5 compatible browser but actually it is communicating through command line but not access windows screen like in Linux. see this for reference as described above ... http://i.imgur.com/1r7tt.png

[snorkeyg]

What windows VNC server are you using? I cant see any I recognize in you system tray.

I just ultravnc, and one option you will have to change is allow loop back connections in whatever server you are using.

Hope that helps.

[vicky555]

Thank you so much snokeyg for your kind response..yes exactly i am missing this step.. can you tell me how to configure ultravnc and websockify.? I already compile and get and exe file of websockify... In linux i am using tightvnc for server and launch the script and can easily accessed the desktop but in windows i dont find any command that how to link websockify and VNC server...

[snorkeyg]

Happy to help. I recommend using ultravnc server grab it and install.

Once installed run ultravnc server. Tick the option 'allow loopback connections' note the port it is running on (default 5900). Then restart server.

Then run Websockify with the as following: Websockify 127.0.0.1:5900 127.0.0.1:7000

Then you should be able to connect with novnc on op 127.0.0.1 port 7000 on the local pc.

[vicky555]

I followed your steps as described above...and i tried different option and doest not connect ..:(
Please see the following effect. i run the ultervnc server and in command line i run the command. C:\Python27\python.exe websockify 127.0.0.1:5900 127.0.0.1:7000

It shows following output when i access through browser.

C:\web\utils>C:\Python27\python.exe websockify 127.0.0.1:5900 127.0.0.1:7000 WARNING: no 'resource' module, daemonizing decode may be slower WebSocket server settings:

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

• proxying from 127.0.0.1:5900 to 127.0.0.1:7000

  1: 127.0.0.1: Normal web request received but disallowed

  2: 127.0.0.1: ignoring socket not ready

  In my second attempt i tried with following options.

C:\Documents and Settings\waqasr>cd ../../

C:>cd web

C:\web>cd utils

C:\web\utils>C:\Python27\python.exe web.py 9095 ('serving on port', 9095)

in browser....http://127.0.0.1:9095/vnc.html
then firefox shows the following error..

New state 'ProtocolVersion', was 'connect'. Msg: Starting VNC handshake util.js (line 71) New state 'failed', was 'ProtocolVersion'. Msg: WebSock error: [object Event] case 'error': Util.Error = function (msg) { console.error(msg); }; util.js (line 72) The connection to ws://127.0.0.1:5900/ was interrupted while the page was loading. websocket = new WebSocket(uri, 'base64'); websock.js (line 264) Received onclose while disconnected case 'error': Util.Error = function (msg) { console.error(msg); }; util.js (line 72) New state 'failed', was 'failed'.

and in command line

C:\web\utils>C:\Python27\python.exe websockify 127.0.0.1:5900 127.0.0.1:7000 WARNING: no 'resource' module, daemonizing decode may be slower WebSocket server settings:

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

• proxying from 127.0.0.1:5900 to 127.0.0.1:7000

  1: 127.0.0.1: Plain non-SSL (ws://) WebSocket connection 1: 127.0.0.1: Version hybi-08, base64: 'True' 1: connecting to: 127.0.0.1:7000 1: handler exception: [Errno 10061] No connection could be made because the target machine actively refused it

now kindly suggest me solution for this problem..it will be great help fore me.. :)

[kanaka]

Actually, the command needs to have the parameters reversed and the first parameter needs to not use 127.0.0.1 unless the server, websockify and noVNC are all being used from the same machine (which doesn't seem particularly useful):

Websockify :7000 127.0.0.1:5900

The first port is the one that noVNC connects to. The second is the address where the server is running. If you are running websockify on a different machine than where the VNC server is running you will need to use the actual IP or hostname of the server rather than 127.0.0.1 (localhost).

Also, I recommend running websockify using python 3.2. To use python 2.7 you will need to use a patched version of websockify (unless you are directly using snorkeyg's binary which is already patched). The patch only allows a single client connection at a time.

[vicky555]

Its working now..thanks alot of kanaka and snorkeyg..It was not possible for me to run this without your help..I will let you know if i need any help.. :)

[eph214]

hi guys,

i'm getting this error with python 3.2 and the latest noVNC on winxp:

C:\noVNC\utils>c:\python32\python.exe c:\noVNC\utils\websockify :8080 127.0.0.1: 5900 WARNING: no 'resource' module, daemonizing decode may be slower 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

any ideas? i attempt to telnet to port 8080 on this machine from another host and it immediately closes the port.

[kanaka]

@eph214 on Windows, you need to have a symlink called websockify.py that points to websockify. The reason is that the way that python does multiprocessing on Windows requires the main python file is re-imported on "fork".

I just pushed a change to add a symlink. I'm not really familiar with how git handles symlinks on Windows so the change may or may not work. Can you verify whether simply updating your repo makes it work? I think that is probably the last win32 issue before I declare websockify to work in Windows using python 3.2 and close this issue.

[kanaka]

Actually, anybody listening on this bug with easy access to test websockify on Windows could test this for me. I've only made the change in the noVNC repo so far. Just do a fresh checkout of noVNC on Windows, run websockify normally, and try connecting to make sure the import error doesn't happen. Thx!

[kanaka]

Actually, made the same change in the websockify repo if you want to test it that way.

[jmcintyre]

I did a fresh grab of code. git creates a copy of websockify as websockify.py instead of a symlink. I didn't test it fully, but it will probably run that way (it did when I did that in testing months ago). I'm not sure how git will handle it during development since there are now two physical copies on a windows system for a single real file in the repo.

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