eureca.io : a nodejs bidirectional RPC library using engine.io or sockjs as transport layer

[Ezelia]

Some time ago I posted here about eureca a nodejs RPC library.

after many enhancements and some documentation I'm releasing a new version with a small name change

here is eureca.io
 
Features :

• Transparent bidirectional RPCs
• Namespaces
• Events
• Different server modes : standalone / attached to http server / attached to express
• Transport layer agnostic (the current version can use engine.io or sockjs)
• Custom websocket path
• Small message exchange
• Nodejs client or browser client

 

the library is available here : http://eureca.io/
 
and a tutorial to build a tchat app is available here : http://eureca.io/tchat-tutorial.html
 


this library is meant to be used in multi-players games or any client-server apps, it hides all socket stuff and make server side functions available to client and vice versa.

[Chris]

Hey, nice to see you wrapped this up for other people to use!

I will much likely use it together with my 8bit tilebased engine for my game instead of re-inventing the wheel again

 

I have a couple of questions, tough:

 

 

In your "Base example" on line 8, you call:

 

eurecaServer.attach(server);

The question is: Are you attaching eurecaServer TO the httpServer, or the httpServer to the eurecaServer?

I assume you are attaching TO the httpServer, to deliver the eureca.js clientside library. Maybe it becomes clearer when you rename that function to "attachTo" or "useHTTP".

 

 

When I want to call clientside functions from the server, I have to set up some kind of init function on the serverside that has to be called from clientside.

After that init function has been called, I have the connection object available through which I can call clientside functions in return?

How about firing a event on serverside whenever a new client connects? - Ah nevermind, I just saw that this is possible, maybe you should edit that example

[Ezelia]

Hello Chris,

glad to see that my library interest you

the attach syntax behaviour is to attach eureca.io TO http/express server as you said, I used attach() cause this is the same name used in engine.io so people comming from engine.io/socket.io don't see the change

I'm not sure to understand your second question, if you need to call client side functions from the server, just initialise the server object telling him witch client side functions are available.

for example if you initialise the server like this :

 

 

var eurecaServer = new EurecaServer({allow : ['ns.foo', 'myMath.add', 'hello']}); 

 

you'll be able to call client side ns.foo(...args), myMath.add(...args) and hello(...args)

and yes you can detect when a client connect ... for example If I take the above example I can write on the server side

 

 

eurecaServer.onConnect(function (connection) {var client = eurecaServer.getClient(connection.id);client.hello();client.ns.foo(1,'str',2);client.myMath.add(5, 10).onReady(function(r) { /* Addition result is returned in r */} );}); 

 

I think you didn't see the tutorial example take a look here http://eureca.io/tchat-tutorial.html (or just download the example tchat app in the bottom of the page).

 

 

btw, in the other post you suggested me to replace functions names by ids,  I implemented it here but it's still experimental.

if you want that functions names don't apear int he websocket messages you can add {useIndexes:true} to the EurecaClient and EurecaServer constructors .... I'll change the parameter name later this is why I didn't document it .

[Chris]

Hm, why do you have to introduce clientside methods to the server?

[Ezelia]

if I don't introduce them I have to add a negociation phase each time a client connect, the client must send its declared functions to the server.

 

for each declared function the server will create a local object (in the server side).

so imagine if the it's up to the client to declare whatever function he want ... a user can declare thousands (millions) of fake functions making server to overload memory and hang

[Chris]

Well, you could skip this completely by using a scheme like this:

 

client.call('my.namespaced.method', param1, param2, ...);

or more verbose:

 

client.method('my.namespaced.method').call(param1, param2, ...);

 

This way, you can completely ignore the pre-definition of client-side methods.

[Ezelia]

I know but I wanted to make the call more "natural"

also, the stub is generated once, if you use your method I'll need to dynamically generate the stub each time I call the function. (parsing namespace ...Etc)

the idea is to have the same syntax in both client and server side while keeping it as close as possible to JS standard syntax.

[Chris]

You don't have to re-parse them on every call but can cache them in an object:

var cache = {    'my.namespaced.method': [something cached]}

But I can see the benefits of keeping the calls more JS-like.