Home > Delphi, JavaScript, Object Pascal, OP4JS, Smart Mobile Studio > Websocket, WebSocket.io and Socket.io

Websocket, WebSocket.io and Socket.io

October 16, 2016 Leave a comment Go to comments

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.

As you may know, node.js gives your JavaScript more or less the same functionality as classical programming languages. You get to work with sockets, talk to databases, implement protocols – all of it in JavaScript and all of it capable of doing exactly what we are doing in Delphi. That is pretty neat!

This is so fun to make and work with

This is so fun to make and work with

But that also means someone has to expose the node.js functionality in pascal form and then write thin wrappers around that. This is where Smart Mobile Studio really shines, because after six years of constant development – we have built up a very powerful codebase. Smart mobile studio is not just about compiling to JavaScript. There are 10-20 compilers out there doing that. Nope, the power of smart mobile studio is in the infrastructure we have painstakingly constructed for our customers. Hundreds of hand-written classes, units and library files. Add to that our cosy little IDE which is very nice to work with and the advantages starts piling up.

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.

Node.js leveraged for object pascal, love it

Node.js leveraged for object pascal, love it

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.

So long story short: you get 3 websocket based server classes to play with, all of them inheriting from TNJCustomServer, so you use the same code to work with all servers. And the speed is phenomenal! I have to pinch myself sometimes just to remember that this is kick-ass javascript running the show.

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.


It’s when I sit and work with the codebase like I do now that I see just how much cool stuff we have. When doing research on a library, how to best wrap or implement it in our RTL, I naturally come across hundreds of comments by JavaScript programmers. Things like allocating memory, copying data from one buffer to the next, working with bytes and bits — a lot of these guys are having a really hard time doing classical programming.

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.



  1. October 17, 2016 at 1:12 am

    This all sounds very exciting; however SMS users would like more frequent, smaller updates. For example send existing new RTL now, then in couple of months, fixes for reported bugs and node.js support and so on.
    Right now biggest problems are silence of SMS team in official groups, lack of good UI (for client side development) and updates. New products like SMS must have much shorter update cycles, monthly or at least quarterly, having one or two updates in a year is not good, there are too many issues.

    • October 17, 2016 at 4:18 am

      I agree. Sadly the project has seen its fair share of tragedy. We had one person who stole our codebase and tried to sell it. We have had one accident which left me unable to work for over a year – and last but not least, we have no patron which supports us financially. But, we have gotten new members to our consortium recently and a meeting is due this week — with everyone excited about getting the product up to a new level.
      So this will be the last “huge” update. We will go for monthly updates instead dealt with by the update manager. So while there have been a couple of rough years making this a reality – hopefully we have reached the point where we all just want to put in whats missing. Focus is on documentation, prefab projects and better ide integration. It would have been different with a sponsor or investor, but until that happens we do the best we can.

  2. October 17, 2016 at 2:03 pm

    Thanks for an update, I hope your book and documentation will fill missing parts for both new and existing/experienced users. Please make sure that one of team members is assigned with moderating SMS groups (lately some spam posts are appearing) and helping users with questions.

  3. October 19, 2016 at 4:12 pm

    The raw TCP is what caught my eye. Was just looking for that yesterday.

  4. October 26, 2016 at 1:24 pm

    This sounds great. I need to develop a client app that works with an Elixir based server system. Hopefully your WebSocket.io can fill the bill. If so, I’ll purchase the professional version.

  5. October 26, 2016 at 2:26 pm

    Hopefully websockets.io can work with an Elixir based server.

    • October 27, 2016 at 2:49 am

      Websocket is the bomb. Its really just http (superfically) but with an subsystem that takes over the whole show. Setting the sockets in async mode amongst other things.
      I use websocket between my raspberry PI based NAS servers (that i have written myself naturally, with a backend in node.js and front-end in chrome/smart app) .. It is faster and better than when i used freepascal + synapse. No disrespect to either, fpc is the bomb and so is synapse — but its the protocol that does the magic here! It just takes awat the whole “repeat -> wait, tokenize message, compile response, send -> until forever” type thinking.
      It changes the way we think about communication.

      You guys should also start looking at async callbacks in delphi. Use my unit for it:

  6. greenboat
    October 27, 2016 at 1:04 pm

    Thanks for the reply.

  1. No trackbacks yet.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: