• I noticed on the developer OpenProject there is a sub-project for node-service … I like writing javascript and somewhat familiar with node … so I was wondering what exactly is the grand plan for node-service?

    Is it something that runs together with node client and queries the FOG server via GET ? Or schedules its own snapins? or the FOG server calls on the client API to have the client execute snapins? I’m not quite sure how snapins fit into this.

    Here is a working example (Windows only, boys) … to install a standalone node and npm … .and to start its own node client. Once the app is loaded - its really up to your imagination what you would like it to do. I suppose together with powershell it can provide a whole heap of statistics - [url]http://nodejs.org/api/os.html[/url]

    Here is what I have:


  • Senior Developer

    Exactly like that

  • Soo … something like this ? (attached)


  • Senior Developer

    Node service is my “baby”, along with the new client. In essence it runs on the server as a “router” for the client. To stick with the networking analogy, the FOG server is the modem, and the clients are the in LAN hosts.

    The new client is purely event-driven, both by local system events and server events. In order to achieve this we must maintain an constant concurrent connection between all hosts and the server.

    The default nature of PHP prevents it from being efficient at maintaining thousands of concurrent connections, not to mention it would flood port 80. The node service is the middle man in-between the FOG server and the client. As it runs on NodeJS, it can maintain millions of concurrent socketIO connections with little ram and cpu usage, due to the non-blocking asynchronous nature of NodeJS.

    That’s just a basic synopsis of the node-service. Theres’ a lot more going on underneath, and more reasons why we have it.

    (Little preview: we also need this style of connection for a future feature. Remote CMD for a client from the FOG web portal. But no promises. We are capable of doing this because of our security-system that Tom & I designed, which is capable of forming a secure connection across unsecured medians, and is immune to session hijacking.)