socketIO-client Development Log

Pay Notebook Creator: Roy Hyunjin Han5
Set Container: Numerical CPU with TINY Memory for 10 Minutes 0


Ensure that Python scripts can communicate with a server.


Integrate at least three pull requests.


Roy Hyunjin Han


Users have invested time in contributing pull requests to the project. We should be responsive to their concerns.


20160330-1200 - 20160430-1200: 1 month estimated

20160330-1200 - 20161211-1200: 9 months actual


+ Integrate at least three pull requests.


20160331-1300 - 20160331-1500

I think that if I allocate a few hours each day, then I should be able to get this done on schedule. s

+ Clone repository
+ Download
+ Work through chat application example
+ Start a new branch

We'll just check whether all unit tests pass. We should also change our tests to use pytest.

+ Check that library works with both versions of

    + Test that works with socketIO-client-0.5.6

        cd ~/Projects/socketIO-client-0.5.6
        python develop
        pip install -I -U nose
        npm install
        node serve-tests

    + Test that works with socketIO-client-0.6.5

        cd ~/Projects/socketIO-client-0.6.5
        python develop
        pip install -I -U nose
        npm install yargs
        node socketIO_client/tests/serve.js

Well, I'm pleasantly surprised. Both tests still pass!

_ Write an experiment to detect version of on server
    + Option 1 is to try to connect with both and avoid the one that fails. But that is naive.
        + Connect socketIO-client-0.5.6 to and see what happens (it just hangs)
        + Connect socketIO-client-0.6.5 to and see what happens (warning: connection refused)
    _ Option 2 is to have more precision by testing certain connection points.

Let's try "Connect socketIO-client-0.6.5 to" again.

WARNING:root:localhost:9000/ [waiting for connection] HTTPConnectionPool(host='localhost', port=9000): Max retries exceeded with url: / (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x7f361b4a1590>: Failed to establish a new connection: [Errno 111] Connection refused',))

After thinking about it some more, I think supporting both protocols in the same library will be needlessly complicated. We will keep the existing structure of having different versions for different protocols.

20160331-2010 - 20160331-2030

+ Add documentation for server SSL certification verification
+ Add documentation for client SSL certification encryption

20160331-2030 - 20160331-2130

+ Work through one pull request

20160403-1100 - 20160403-1200: 1 hour estimated

20160403-1100 - 20160403-1400: 3 hours actual

+ Work through one pull request

20160625-1815 - 20160625-1845: 30 minutes

I am noticing some thread-related errors.

For example, here is an error that appears

Exception in thread Thread-1 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
File "/usr/lib64/python2.7/", line 804, in __bootstrap_inner
File "/home/rhh/.virtualenvs/crosscompute/lib/python2.7/site-packages/socketIO_client/", line 34, in run
File "/usr/lib64/python2.7/", line 617, in wait
File "/usr/lib64/python2.7/", line 367, in wait
<type 'exceptions.ValueError'>: list.remove(x): x not in list
Unhandled exception in thread started by
sys.excepthook is missing
lost sys.stderr

I am looking at line 367 of but it looks like the exception should have been ignored.

except ValueError:

I think the ValueError is coming from somewhere else.


For now, let's just wait for the heartbeat thread to join.


If the exception appears again, then we'll use atexit.register(self._heartbeat_thread.join()).


The issue is that packet_text has utf-8 but we need a bytestring and six.b only encodes using latin-1.

Option 1: Encode packet_text into a bytestring using utf-8, but then we won't be working with unicode.
Option 2: Leave packet_text alone and handle it differently based on whether it is unicode or a bytestring.


After thinking about it a bit, I think the second approach is more robust, because we'll just leave the packet data as it is mostly and just handle it verbatim. The first option can be vulnerable to cases where the packet type might be wrong?


If I ever do revisit binary support, I should try to generate a log of the binary protocol using Chrome Developer Tools. There were some notes about XHR2 vs base64.


The feus4177 repository has a working solution for binary support, but I didn't completely understand how it worked and I felt uncomfortable about merging something without full understanding.

I also wanted to address unicode support and the decision was to keep everything as an encoded bytestring and only decode for non-binary events. I tried the approach of leaving the packet alone and just handling unicode or bytestring on a case by case basis, but it proved too messy.

Perhaps when my life becomes less complex, I'll revisit both binary and unicode support. But for now, I have too many things in my head and my capacity for extra complexity is becoming rather limited.

20161209-2130 - 20161209-2230: 1 hour

+ Make decision on websocket-client issue for #139
+ Merge #139 into 0.7.2

20161209-2330 - 20161210-0000: 30 minutes

+ Merge #125 into

20161210-0045 - 20161210-0115: 30 minutes

+ Merge #136 into 0.7.2

20161210-1100 - 20161210-1200: 1 hour

+ Merge #135 into 0.7.2

20161210-2200 - 20161210-2230: 30 minutes

I tried experimenting for a while with unicode events, where there are unicode characters in the event name, but it seems that Python 2 does not support unicode attributes.

+ Release
+ Release 0.7.2

20170406-1630 - 20170406-1700: 30 minutes

To ensure this package's longevity, it might be prudent to seek a co-maintainer for this package.

For now, let's focus on getting binary packet support merged.