This is learning diary post from Uni Helsinki course Software Factory / Facebook academy – SocketIO team. For more info about this course read “Ready, Set, Start Coding!”.
You can find open issues and questions I collect from past week in my quick project notes.
Focusing on only one thing at a time now
Really busy week behind. Doing studies to two universities at the same time introduces a huge problem, a day just does not have enough hours. Gladly, this is over now on the week 4 since at the University of Paderborn the exam period starts and I don’t have any lectures to attend anymore. Weird German university schedule… And also my brother was visiting me.
The weaknesses of WebSocket protocol
In the Guillermo Rauch’s book Smashing Node.js is a section that describes the weakness of WebSocket protocol and the reasons that lead to the development of Socket.io:
“close” event means that the connection was properly closed, but it does not consider unexpected network events ex. computer closes suddenly or the network is shutdown, in these cases “close” event not ever fire and the server would still keep sending data or the client would be expecting it.
Handling reconnections, WebSocket protocols does not provide mean for handling situations where the client tries to connect back to the service after a temporal disconnect. The only way for the client to reconnect would be to refresh the browser.
Broadcasting the same message to multiple client is a commonly used pattern in many real-time applications, ex. chat application usually sends message to all the participants or a multiplier game sends the move of a player to everyone else. In WebSockets the application has to implement broadcasting mechanism.
It’s not supported yet, many older browsers, firewalls, proxies or antivirus software do not support WebSocket protocol and many users might not be able to use applications implemented with this new technology.
Socket.io provides a solutions for these aforementioned issues. It adds an additional layer of abstraction that provides a simple API for developers effectively send messages in real time web applications, handles unexpected network events by checking if client or server is still connected with heartbeat messages and timeouts. Forevermore it implements mechanisms for broadcasting messages to multiple users and it handles JSON objects automatically so developers can implements communication patterns without worrying about text to JSON conversions.
Creating that first pull request in GitHub
On last week I began to feel that I know the Socket.io structure, tools and techniques sufficiently to fix some issues reported in GitHub, but finding an issue that is up to date and current was not just a matter of simply picking one. Issues and pull requests are a bit outdated, many of them seem to be already fixed or vaguely described. Thankfully defunctzombie helped out with this confusion and confirmed that the one I selected is actually relevant.
Starting from something simple
One issue that looked like it could be easily fixed and would serve as a good point to start from is number 232 in Engine.io-client.
Flashsocket transport functionality in Engine.io-client needs automated test cases that verify the implemented code works. All the tests in Socket.io are written using Mocha testing framework, which is a new acquaintance to me. Learning a new tool always makes things more interesting, especially, because I know that many Node.js projects use Mocha.
Upcoming things on the list are to write test cases that give a good coverage over the tested functionality, commit changes and fill a pull request.
Next stop San Francisco
During next weekend all the participants of Facebook Academy will attend to hackaton organized in San Francisco, and I could not be more thrilled about the trip. It will be great to meet all the members of Socket.io team and our mentors.