win32 support about websockify HOT 68 CLOSED

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)

from websockify.

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/

from websockify.

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

from websockify.

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?

from websockify.

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.

from websockify.

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

from websockify.

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?

from websockify.

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

from websockify.

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.

from websockify.

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

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

from websockify.

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

from websockify.

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

from websockify.

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.

from websockify.

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()

from websockify.

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

from websockify.

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

from websockify.

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

from websockify.

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)

from websockify.

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.

from websockify.

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.

from websockify.

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?

from websockify.

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

from websockify.

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.

from websockify.

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.

from websockify.

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?

from websockify.

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.

from websockify.

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.

from websockify.

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.

from websockify.

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)

from websockify.

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

from websockify.

@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:
#2 (comment)

from websockify.

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

from websockify.

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

from websockify.

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

from websockify.

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

from websockify.

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

from websockify.

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.

from websockify.

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

from websockify.

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.

from websockify.

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.. :)

from websockify.

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.

from websockify.

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.. :)

from websockify.

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.

from websockify.

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

from websockify.

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!

from websockify.

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

from websockify.

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.

from websockify.

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.

from websockify.

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.

from websockify.

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 )

from websockify.

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

from websockify.

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.

from websockify.

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.

from websockify.

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.

from websockify.

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.

from websockify.

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

from websockify.

@vicky555 many thanks. Its working now.

from websockify.

@agnivade you are welcome.. :)

from websockify.

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

from websockify.

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

from websockify.

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/

from websockify.

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.

from websockify.

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

from websockify.

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.

from websockify.

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

#3

from websockify.

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

from websockify.

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.

from websockify.

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

from websockify.