Websocket, WebSocket.io and Socket.io
Wow. Thats is a mouthfull isn’t it? Websocket, websocket.io and socket.io. So what is that all about?
In short, im finishing off the server units for Smart Mobile Studio! And I think people are going to be super pleased and happy about this one.
Servers, glorious node.js servers
So whats on the menu? A lot! More than I actually thought we would add in the next update. Here is a list of the server types you will be getting:
- http server
- websocket server
- tcp/ip server
- socket.io server
- websocket.io server
To explain the differences:
Websocket is a full-duplex communication stack that allows both client and server to talk; at the same time. It also contains fancy commands for emitting messages to all connected clients, and likewise a client can commit messages to other clients (if the server allows it). You can send both text messages and binary messages. And the cool part is that the websocket engine will collect the data, deal with net-frames and spare you all the razzle you would otherwise have to do.
On top of this we have something called socket.io. This takes the whole thing one step further, allowing you to define a set of commands on the server (by name), and associate that with the code to execute when such a command is received. Socket.io also come in client-form for both browser and node.js itself. And just like the server edition you can define a set of commands for the client as well. This moves websocket into the realm of real-time messaging, where rather than wasting days and weeks coding your own protocol, you can kick back and flesh out your command-set much in the way RemObjects SDK does. Socket.io also contains clustering mechanics, but I wont cover that just yet.
Websocket.io is sort of third option. It’s basically websocket and socket.io glued together. You don’t have to upgrade the http socket (read up on websocket if you have no clue what that means) if you don’t want to. Websocket.io gives you pretty much exactly the same as websocket + socket.io, but from a unified API. And to be honest this is the library I use the most myself.
If you think websocket is “communication with training wheels” (I don’t, I frikkin love it) then a raw TCP server is probably your cup of tea. This is a perfect class to use if you need to port over some old Delphi code, if you for some reason hate XML or JSON – or perhaps you just want to dump over raw binary data as quickly as possible. Either way: it’s there, and it works brilliantly.
As you would expect I’m also doing the client side of things. We have supported websocket out of the box for a while now, and I just added a socket.io client to the codebase. I have a few alternatives to try out on the raw tcp stuff, but ultimately tcp is now allowed for HTML5. But a client and server for node.js is ofcourse on the menu.
But for Smart Pascal that’s not even an issue. We have supported memory allocation, blue-pointers and even a threading model for quite some time now. Yes, threading. Check your RTL folder and you will find it 🙂 It goes without saying that when you have memory streams, file streams, raw buffer classes, stacks, queues and proper inheritance that smart pascal gives you more than just a head-start. The benefits are astronomical in places.
And no, im not just blowing my own horn here — I use Smart Mobile Studio to create services and mobile applications on a daily basis. So I am painfully aware of what we did wrong, but also what we did right. And thankfully we got more right than wrong.